March 1, 2026
Marketplace Foundations and Orchestrator Unification
This update introduces a dynamic embodiment catalog, unifies the core ACT execution logic, and adds a multi-stage document intelligence pipeline.
Embodiments Marketplace
We’ve moved away from hardcoded placeholders and fragile ZIP uploads toward a dynamic, git-tag-based marketplace. The new catalog allows for installs directly from a curated manifest or custom URLs, resolving the latest tags via ls-remote to ensure stable versions are used. A new tool_update_service now runs every 6 hours in the background to check for new tags, providing update badges and a safe swap-and-validate flow for existing tools. This ensures tool configurations survive updates while keeping the underlying implementation fresh.
Unified ACT Orchestrator
One of the most significant architectural improvements in this cycle is the consolidation of the ACT execution loop. Previously, the logic was triplicated across various workers, leading to diverging features and bugs like inconsistent critic behavior or missing repetition detection. We’ve replaced these with a single ACTOrchestrator service. This refactor also centralizes skill sets and action categories into immutable frozensets, eliminating ‘stale skill’ errors and fixing several UI-level card duplication bugs that occurred during critic retries or SSE reconnections.
Document Intelligence Pipeline
We’ve implemented a comprehensive document processing pipeline that handles PDF, DOCX, and other major formats. Unlike standard RAG implementations, this features a two-phase confirmation flow: documents are processed, metadata is extracted via regex, and an LLM generates a synthesis that the user must review before the document is marked as ‘ready.’ We’ve also added a supersession system, where newer versions of a document can automatically replace and soft-delete older iterations. Search is now a hybrid of semantic embeddings (via pgvector) and full-text search with keyword boosting.
System Readiness and Stability
To improve the initial user experience, we added a backend readiness probe. The frontend now polls a /ready endpoint that specifically checks the health of PostgreSQL, Redis, and the registration of workers on the prompt-queue. The ‘spark’ loading overlay now persists until the entire subsystem is confirmed alive, preventing users from interacting with a UI that doesn’t have a functional background worker behind it yet.