Foundations for Intelligence

Unifying the Agent’s Core

The core agent execution logic—our ACT loop—was triplicated across the tool_worker, digest_worker, and persistent_task_worker. Over time, these implementations had silently diverged, creating subtle inconsistencies. For instance, the critic was only running in one worker, a budget safety net was exclusive to another, and smart repetition detection was missing from the third. This was a classic DRY violation waiting to cause problems.

Today, we replaced all three with a single, parameterized ACTOrchestrator service. This refactoring centralizes the execution logic, ensuring every task benefits from the same safety checks, critic oversight, and efficiency improvements. As part of this cleanup, we also consolidated scattered constants like skill sets into central registries and fixed several nagging card duplication bugs stemming from race conditions and retry logic.

Introducing the Document Intelligence Pipeline

A major new capability landed today: a complete pipeline for ingesting and understanding documents. Users can now upload common file types (PDF, DOCX, PPTX, etc.), which Chalie will process end-to-end.

The pipeline automatically extracts text, identifies key metadata like dates and companies, and uses adaptive chunking to store the content with semantic embeddings in pgvector. An LLM then synthesizes a human-readable summary and a list of key facts. Crucially, this synthesis isn’t final until the user confirms it, allowing for review and augmentation with personal context. The system also handles versioning through supersession—uploading a newer version of a document intelligently replaces the old one. This entire knowledge base is now accessible via a new document skill, enabling hybrid search across everything a user has uploaded.

Ensuring a Smooth Startup

We fixed a frustrating startup race condition. Previously, the frontend would load the moment the web server started, often before the database, Redis, or background workers were fully initialized. This could lead to a confusing or non-functional initial state.

We’ve introduced a new /ready endpoint that acts as a true readiness probe, only returning a success status when PostgreSQL, Redis, and the necessary queue workers are all confirmed to be online. The frontend now polls this endpoint, displaying a “Waking up…” overlay until the entire system is ready. This provides a much more robust and reliable startup experience, preventing users from interacting with a partially-active system.