## Plan for Technical Documentation: Herandro Ecosystem V8

### 1. Objetivo de la documentación  
The documentation will serve as a **comprehensive technical analysis, architecture guide, and implementation blueprint** for the Herandro Ecosystem V8 – a scalable, multi-user AI assistant. It covers the entire stack from asynchronous ingestion to persistent graph memory, and provides actionable recommendations for tooling, libraries, infrastructure, and deployment.  
The target output is a single, self-contained document that enables a senior engineering team to:  
- Understand the system’s design and data flows.  
- Select the most efficient libraries and tools based on current best practices.  
- Implement the core services (API, workers, Telegram bot) with production-grade configurations.  
- Deploy the stack on Coolify using Docker Compose.  
- Integrate with Telegram via webhooks and async workers.  
- Use generated diagrams (architecture, ER, flow, class) to onboard new developers.

### 2. Audiencia y nivel técnico  
**Primary readers:**  
- Senior backend developers (Python, async frameworks)  
- DevOps / SRE engineers managing deployment and scaling  
- System architects evaluating the design  

**Expected prerequisites:**  
- Proficiency with Python 3.11+ and asynchronous programming (asyncio, FastAPI)  
- Experience with Docker, container orchestration (Coolify / Docker Compose)  
- Familiarity with message brokers (Redis), task queues (Celery), and multi-model databases (SurrealDB)  
- Basic understanding of Telegram Bot API and webhook mechanics  
- Knowledge of authentication flows (OAuth2/OIDC, Keycloak)  
- Familiarity with graph databases and RAG concepts is helpful but not mandatory

### 3. Alcance y versiones  
**Covered:**  
- Herandro Ecosystem V8 as described in the provided guidelines (Architecture & Database Schema)  
- Latest stable versions of all core components as of Q2 2025 (Python 3.12, FastAPI 0.115+, Celery 5.4+, Redis 7.2+, SurrealDB 2.x, aiogram 3.x, etc.)  
- Tooling comparisons and justifications for Celery (open-source self-hosted), SurrealDB, RAG vector store (e.g., Qdrant, Weaviate, Chroma), CDN options, and LangGraph alternatives  
- Docker Compose and Dockerfile specifically tailored for Coolify deployment  
- Diagrams: Infrastructure Architecture, System Modules, Entity-Relationship, Data Flow, Class Diagram for core agents, and Sequence Diagrams for key workflows  
- Integration with Telegram (webhook handling, media upload, context loops)  
- Research into similar agent architectures and lessons learned (e.g., LangChain-based assistants, multi-agent systems, RAG pipelines)  

**Out of scope:**  
- Phase 2 Angular dashboard (mentioned but not implemented)  
- Detailed Keycloak setup (only integration points)  
- Production monitoring, logging, and CI/CD pipelines (brief mentions only)  
- Payment or billing systems  
- Non-Telegram interfaces (WhatsApp, web chat)

### 4. Estructura del documento  
The final document will be organized as follows:

1. **Introduction**  
   - Project vision, objectives, and high-level overview  
   - Glossary of terms (Herandro ecosystem, user facts, RAG, etc.)

2. **Architecture Overview**  
   - High-level system diagram (Mermaid) showing all layers  
   - Explanation of each layer: Interface, Intelligence, Temporal/Async Engine, Persistence & Indexing, RAG Knowledge System  
   - Design principles: decoupling, scalability, cost-efficiency

3. **Technology Stack Recommendations**  
   - Detailed comparison of candidate libraries/tools for each component  
     - Task Queue: Celery (self-hosted) vs alternatives  
     - Vector DB: Qdrant, Weaviate, Chroma, Milvus (criteria: self-hosted, performance, SurrealDB integration)  
     - CDN: MinIO, Backblaze B2, or S3-compatible storage  
     - NLP/LLM Orchestration: LangGraph vs custom lightweight agent framework  
   - Final recommended stack with version pinning  
   - Justifications based on the project’s constraints (open-source, self-hosted, no vendor lock-in)

4. **Infrastructure & Deployment (Coolify + Docker Compose)**  
   - Network topology and resource allocation  
   - `docker-compose.yml` for the entire stack (Redis, SurrealDB, Celery worker & beat, FastAPI, optional vector DB)  
   - `Dockerfile` for the Celery worker optimized for Coolify (multi-stage build, non-root user, health checks)  
   - Coolify specific configurations (environment variables, secrets, volume mounts)  
   - Diagram: Infrastructure deployment view

5. **Core Components in Depth**  
   - **FastAPI Webhook Layer**  
     - Endpoint design, payload validation, immediate 200 OK, Redis offloading  
     - Middleware for authentication (Keycloak JWT)  
   - **Celery + Redis Asynchronous Engine**  
     - Queue architecture (`default_messaging_queue`, `heavy_asset_queue`)  
     - Task definitions (media analysis, URL scraping, OCR)  
     - Beat schedule for recurring reminders  
     - Fault tolerance, persistence, and retry strategies  
   - **SurrealDB Multi-Model Schema**  
     - Implementation of the defined tables with SCHEMAFULL/SCHEMALESS  
     - Graph edges and traversal examples  
     - Indexing strategy and performance considerations  
   - **RAG Knowledge System**  
     - Integration of a vector DB with SurrealDB index pointers  
     - Chunking, embedding, and retrieval flow  
     - CDN asset storage and Markdown processing  
   - **aiogram Telegram Bot**  
     - Webhook setup (with self-signed or Cloudflare Tunnel for Coolify)  
     - Intent routing and tool dispatch  
     - Handling multimedia, voice, and files  

6. **Agent Core Intelligence & Tools**  
   - Classification and intent recognition pipeline (lightweight LLM calls)  
   - Tool definitions per the project spec, with pseudo-code  
   - Dynamic memory interrogation and context management  
   - Class diagram: central Agent class, Tool base, and concrete tools  

7. **Entity-Relationship & Data Flow Diagrams**  
   - ER diagram (Mermaid) based on SurrealDB schema  
   - Sequence diagrams for:
     - Incoming text processing and fact indexing  
     - Multi-user group reminder with opt-in cascade  
     - Heavy asset processing (image → description → index)  
   - Data flow diagram showing the journey of a Telegram message from webhook to persistent memory  

8. **Telegram Integration Cookbook**  
   - Bot registration, webhook configuration, security (secret token)  
   - Best practices for handling Telegram’s retry and timeout constraints  
   - Code examples for file download, CDN upload, and acknowledgment  

9. **Case Studies & Similar Projects**  
   - Analysis of existing open-source AI assistants (Open Interpreter, GPT-Researcher, LangChain bots)  
   - What worked, what didn’t, and how Herandro graph/RAG hybrid approach differs  
   - Lessons on scaling, cost control, and memory management  

10. **Best Practices & Recommendations**  
    - Security: API token rotation, environment isolation, network segmentation  
    - Performance: caching strategies, database connection pooling, worker concurrency tuning  
    - Maintainability: code organization, configuration management, testing strategies  
    - Future‑proofing: how to swap components (e.g., change vector DB) with minimal impact  

11. **Appendices**  
    - Full `docker-compose.yml` and `Dockerfile` listings  
    - Sample environment files  
    - SurrealDB initialization script  
    - Keycloak integration notes  

### 5. Aspectos técnicos a investigar  
To produce this documentation, the following items require external research and verification:

- **Latest stable releases** of all dependencies (Celery, Redis, SurrealDB, aiogram, FastAPI, etc.) and compatibility matrix  
- **Coolify deployment specifics** for Python/Redis services: volume handling, health checks, reverse proxy configuration  
- **Celery in production**: best worker type (prefork vs eventlet), broker visibility timeout, result backend settings  
- **SurrealDB 2.x** performance on graph queries, indexing strategies, and any breaking changes from earlier versions  
- **RAG vector database comparison** focusing on self-hosted, low-latency options that work well with Python clients  
- **LangGraph vs. custom agent frameworks** – performance overhead, flexibility, and real-world case studies  
- **Telegram webhook requirements** in 2025 (certificates, IP restrictions) and how to expose a Coolify instance securely  
- **Open-source CDN alternatives** (MinIO vs Garage) suitable for small to medium asset storage  
- **Similar AI assistant architectures** that combine graph memory, RAG, and task queues; gather concrete architectural patterns and pitfalls  
- **Performance benchmarks** for message throughput under typical loads to guide worker scaling  

### 6. Convenciones  
- **Code blocks**: Python, bash, Dockerfile, and SurrealQL snippets; all in triple backticks with language identifiers.  
- **Diagrams**: Mermaid syntax for architecture, ER, flow, and sequence diagrams.  
- **Notes / Warnings**: Use blockquotes with “> **Note:**” or “> **Warning:**” prefixes to highlight critical configuration details.  
- **Naming**: Consistent lowercase with underscores for Python files, functions; CamelCase for classes. Docker service names match the component.  
- **Configuration**: Environment variables in `UPPER_CASE`; sensitive values shown as `your-...` placeholders.  
- **Version references**: Include explicit version numbers, not “latest”.  

### 7. Entregable esperado  
The final deliverable is a **single Markdown document** (with embedded Mermaid diagrams) that serves as both a detailed research report and a practical implementation guide. It will contain:  
- Executive summary and architecture overview  
- Full technology stack analysis with reasoned recommendations  
- Production-ready Docker Compose and Dockerfile for Coolify (commented and explained)  
- Complete SurrealDB schema scripts and indexing recommendations  
- Step-by-step implementation for each core service, including code snippets for key logic  
- All requested diagrams rendered in Mermaid  
- A dedicated section with concrete integration steps for Telegram  
- A collection of learnings from similar projects and a synthesis of best practices distilled for this specific ecosystem  

The document will be written in clear, objective technical English, targeting a team that needs to build and operate this system immediately. All claims will be backed by the research findings, and every diagram will be accompanied by an explanation of the depicted flow.

### 8. Context about project
Architecture & Database Schema
Guidelines for the Erando Ecosystem V8
The herandro-services-api ecosystem is designed to be a highly scalable, stable, and
multi-user assistant capable of managing real-time reminders, contextual dynamic memory
(User Facts), and deep knowledge management without exhausting LLM context windows or
incurring over-engineering overhead. Authentication is entirely decoupled and offloaded to
Keycloak.
1. Core Layers & Technical Stack Overview
Layer Technology Stack Responsibility
Interface Layer Telegram Bot (aiogram) +
FastAPI (Python)

Integrated via asynchronous
Webhooks. Avoids polling
and handles real-time
messaging with minimal
footprint. Includes an
Angular dashboard in Phase
2.

Intelligence Layer herandro-services-api
(LangGraph / custom agent
frameworks)

Orchestrates small,
lightweight classification and
extraction agents instead of
resource-heavy deep
sub-agents. Manages
runtime intent routing and
state evaluations.

Temporal & Asynchronous
Engine

Celery + Redis Broker Manages background tasks,
long-running asset parsing,
media processing, and
persistent multi-interval cron
execution decoupled from

Layer Technology Stack Responsibility
HTTP routines.

Persistence & Indexing SurrealDB (Multi-Model
Graph & Document DB)

Acts as the structured
relational/graph index for
users, groups, reminders,
metadata, and RAG
document pointers. Handles
complex entity edges
natively.

RAG Knowledge System External Vector Repository +
CDN Asset Storage

Stores high-volume text
chunks, project definitions
(e.g., code setups, clean
code principles), raw
conversational memories,
and flat structural Markdown
files.

2. Project Vision & Framework
A. Project Meta (Main Goal)
To develop a centralized, secure, server-less cost-efficient, and highly contextual assistant that
acts as a dynamic long-term memory hub. The system must natively capture conversation
details, parse and index media or file assets through a CDN, handle multi-user grouped
workflows (Family, Panas, Groups) with opt-in confirmation mechanics, and process
asynchronous temporal jobs without data loss upon server reboots.
B. Specific Objectives
● Unified Authentication & Identification: Securely link Keycloak identities and CakePHP
shared user repositories (mapping the sub, name, email, and API tokens) with Telegram
unique telephone numbers and chat IDs.
● Hybrid Storage Optimization: Utilize SurrealDB as the structured graph router for

semantic tags, summaries, and relations, alongside a CDN for heavy unstructured
objects, keeping LLM token overhead low.
● Intelligent Content Scraping: Deploy automated scrapers to parse raw incoming URLs
directly into streamlined Markdown, avoiding expensive HTML parsing loops.
● Group Synchronization Dynamics: Implement an asynchronous message dispatch tree
where a group reminder cascades into individual user spaces for independent
confirmation or cancellation.
● Persistent Task Reliability: Establish an open-source, zero-cost task scheduling engine
providing fault-tolerant persistent crons and intervals.

3. Intelligent Agent Core Persona & Runtime
Characteristics
A. Behavioral Autonomy & Intent Routing
The agent operates as a text-driven, asynchronous conversational intelligence. Every user
interaction via chat is treated as a potential context modification or tool-triggering event.
Instead of rigidly following sequential hardcoded rules, the agent analyzes conversational state
and context maps to autonomously decide which operational tool to leverage. It is explicitly
designed to handle loose temporal constraints, conversational corrections ("forget what I said
about yesterday"), and abstract multi-user dependencies without stalling the core chat
feedback loop.
B. Personalized Context Management Dependency
The system enforces a strict runtime dependency for personalized context processing. The
agent must continuously track and refine user specific parameters, personal preferences,
domain constraints (such as software development clean code principles), and local history.
This allows the intelligence layer to resolve ambiguous input parameters correctly based on
historical interaction vectors without forcing the user to repeat functional background
conditions.
C. Graph-Based Memory Structure
Memory is structurally handled through a native graph paradigm utilizing SurrealDB's relational
edge capabilities. Instead of treating historical conversational turns as flat JSON logs, user
declarations, group bounds, categorization nodes, and semantic metadata mappings are

connected via edge verbs (e.g., belongs_to, has_category). This allows deep relational
traversals with O(1) index overhead, empowering the agent to resolve indirect data
associations like cross-referencing family members to a shared reminder cluster cleanly.
D. Supported Capabilities & Structural Scope
● Dynamic Memory Interrogation: Natively resolves abstract queries (e.g., "What did I
mention about my novia last week?") by utilizing structured summary maps before
escalating to raw data iterations.
● Multi-Format Media Processing: Ingests photos, code snippets, visual attachments,
documents, and plain web links, routing execution blocks safely to decoupled workers.
● Proactive Action & Notification Trees: Autonomously identifies shared group
commitments, cascades opt-in prompts to involved ecosystem members, and maps
separate validation flags into user spaces.
E. Operational Limits & Error Boundaries
● Asset Scrape Optimization: URL tracking and scraping tools strictly output clean, flat
Markdown. Deep native raw HTML tree tracking or continuous background scraping of
volatile dynamic JavaScript pages is unsupported.
● Context Failure Loop Prevention: If a targeted query is not found within the local
SurrealDB descriptive index summaries, the agent performs an isolated full RAG semantic
search. If no data boundaries are matched, the agent will explicitly state its tracking
limitations rather than generating unverified assumptions or hallucinating content.

4. Asynchronous Processing & Webhook Decoupling
A. Webhook Handlers & Timeout Prevention
To comply with Telegram's strict webhook execution constraints (requiring a response within a
few seconds to avoid retries and message loops), the HTTP Interface layer running via FastAPI
acts strictly as an ingest router. When an update containing media assets, files, or complex
content arrives, the API immediately saves the file reference to the CDN, acknowledges the
webhook with an HTTP 200 OK status, and non-blockingly routes the resource payload to
Redis.
B. Concurrency Architecture & Responsiveness

The Celery implementation isolates heavy execution pathways into specialized queue
architectures to prevent complex background workloads from blocking immediate text
responses:
● default_messaging_queue: Processes short, inbound text extractions and rapid
conversational turn calculations using lightweight LangGraph structures.
● heavy_asset_queue: Handles long-running background workers running image
description parsing, text scraping from URLs, optical character recognition (OCR), and
document transformations to Markdown.
By defining decoupled worker concurrency counts (e.g., eventlet or prefork pools), workers
reading from the messaging queue instantly reply to subsequent, new user queries. If a user
asks, "Did you finish parsing that image?", the conversational agent query immediately checks
SurrealDB's index state without waiting for the slow heavy_asset_queue to resolve.

5. Sequential Development Execution Plan
Task 1: Database Initialization & Relations (SurrealDB)
● Initialize SurrealDB production instance and execute structural SCHEMAFULL table
schemas for user, user_group, user_fact, and knowledge_index.
● Verify unique constraints on keycloak_sub index definitions.
● Seed mock relation layers testing graph edge mutations using native record link pointers.
Task 2: API & Core Ingestion Routing Framework (FastAPI)
● Construct FastAPI base server structure containing request validation middleware and
dependency injection setups.
● Build secure endpoints to map incoming shared user records against custom Keycloak
auth claims.
● Implement core webhook handling route to immediately offload incoming complex
update payloads into Redis, establishing zero-block request operations.
Task 3: Background Worker Infrastructure & Cache (Celery + Redis)
● Establish decoupled queue routers: separate immediate conversational processing
blocks (default_messaging_queue) from long-running background processors
(heavy_asset_queue).
● Write atomic task configurations for asset analysis workflows, URL scrapers transforming
raw endpoints to Markdown format, and background OCR tracking.

● Integrate Redis key-value eviction stores for caching conversational state contexts.
Task 4: Conversation Engine & Chatbot Interface (aiogram)
● Configure the aiogram polling/webhook controller to catch Telegram channel updates
securely.
● Implement state routing mechanisms matching user intent dynamically against
predefined atomic agent tools (such as create_contextual_reminder or
query_user_facts).
● Integrate file, document, photo, and voice message payload handlers to seamlessly
upload blobs to CDN structures before scheduling task runs.
Task 5: Management Dashboard Interface (Angular UI - Phase 2)
● Scaffold the responsive administration web UI using Angular 18+.
● Construct authorization guards linking Keycloak state attributes natively with front-end
router pipelines.
● Build clean data visualization tables to browse descriptive summary indices, manage
explicit tags, and track active group broadcast permissions.
Task 6: End-to-End System Integration Testing
● Perform isolation checks on simulated server reboots to guarantee task worker crons
remain intact inside persistent storage schemas.
● Verify concurrent text queries resolve properly over default_messaging_queue while
slow image extractions run inside heavy_asset_queue.
● Validate multi-user group cascading notification triggers and opt-in flag resolution
patterns.

6. Agent Core Tools (Tools Definition)
The intelligence layer utilizes an atomic, agent-based decision-making toolset. Instead of
hardcoded logical paths, the LangGraph orchestration layer routes intent dynamically to
specialized tools based on intent classification, payload sizes, and asset types:
A. Asset Ingestion & Conversion Tools
● analyze_media_asset(cdn_url: str, mime_type: str) -> str: Invokes visual or text-extraction
models to analyze images, PDFs, or files from the CDN, returning a structural Markdown

overview and generating lookup indices. This operation executes asynchronously via
Celery background tasks.
● scrape_and_convert_url(url: str) -> str: Scrapes any user-provided web link, extracts
relevant semantic elements, and structures the response entirely into Markdown format.
B. Contextual & Reminder Management Tools
● query_user_facts(query: str) -> list: Queries local relational contextual tables inside
SurrealDB to match specific fluid constraints (e.g., matching "daily" to "09:15").
● create_contextual_reminder(owner: str, content: str, trigger_datetime: datetime, tags: list,
priority: str) -> str: Persists granular scheduling records inside the schema-less reminder
structure, linking custom semantic tags, relative execution priorities, and routing pointers
to Redis queues.
● mutate_reminder_lifecycle(action: str, reminder_id: str, patch_data: dict) -> bool: Executes
runtime changes on reminders (e.g., modifying execution window, updating
categorization paths, or performing soft-deletion loops).
● dispatch_group_broadcast(group_id: str, raw_content: str, scheduled_time: datetime) ->
dict: Splits group events into localized permission blocks, requesting opt-in confirmations
from separate members.

7. SurrealDB Entity-Relationship Schema
-- 1. Identity & Access (Keycloak & Shared Repositories)
DEFINE TABLE user SCHEMAFULL;
DEFINE FIELD id ON user TYPE record<user>;
DEFINE FIELD keycloak_sub ON user TYPE string ASSERT $value != NONE;
DEFINE FIELD name ON user TYPE string;
DEFINE FIELD email ON user TYPE string;
DEFINE FIELD telegram_id ON user TYPE option<string>;
DEFINE FIELD api_token ON user TYPE option<string>;
DEFINE FIELD timezone ON user TYPE string DEFAULT "America/Cancun";
DEFINE INDEX keycloak_sub_idx ON user COLUMNS keycloak_sub UNIQUE;
DEFINE TABLE user_group SCHEMAFULL;
DEFINE FIELD name ON user_group TYPE string;
DEFINE FIELD created_by ON user_group TYPE record<user>;
DEFINE FIELD created_at ON user_group TYPE datetime DEFAULT time::now();

-- Graph Edge: Multi-user & Family/Panas permissions
DEFINE TABLE belongs_to TYPE RELATION IN user OUT user_group;
-- 2. Local Dynamic Context (User Facts)
DEFINE TABLE user_fact SCHEMAFULL;
DEFINE FIELD user ON user_fact TYPE record<user>;
DEFINE FIELD fact_key ON user_fact TYPE string; -- e.g., "daily_meeting_time"
DEFINE FIELD fact_value ON user_fact TYPE string; -- e.g., "09:15"
DEFINE FIELD raw_context ON user_fact TYPE string; -- e.g., "Dailies are Mon-Fri at
9:15"
DEFINE FIELD tags ON user_fact TYPE array<string>;
DEFINE FIELD updated_at ON user_fact TYPE datetime DEFAULT time::now();
-- 3. Reminders & Schedulers (Persistent Open-Source Worker Inputs)
DEFINE TABLE reminder SCHEMALESS; -- Schemaless metadata fields for elastic
configurations
DEFINE FIELD owner ON reminder TYPE record<user | user_group>;
DEFINE FIELD content ON reminder TYPE string;
DEFINE FIELD status ON reminder TYPE string DEFAULT "pending" ASSERT $value
INSIDE ["pending", "completed", "cancelled"];
DEFINE FIELD priority ON reminder TYPE string DEFAULT "medium" ASSERT $value
INSIDE ["low", "medium", "high"];
DEFINE FIELD tags ON reminder TYPE array<string>;
DEFINE FIELD created_at ON reminder TYPE datetime DEFAULT time::now();
DEFINE FIELD next_trigger_at ON reminder TYPE datetime;
DEFINE FIELD cron_rule ON reminder TYPE option<string>; -- e.g., "0 9 15 * *" for
quincenas
-- 4. Dynamic Categories Tree
DEFINE TABLE category SCHEMAFULL;
DEFINE FIELD name ON category TYPE string;
DEFINE FIELD parent ON category TYPE option<record<category>>; -- e.g., Supermercado
/ Necesidades
-- Graph Edge: Reminders categorization mapping
DEFINE TABLE has_category TYPE RELATION IN reminder OUT category;
-- 5. Deep Memory Knowledge Index & Assets (RAG & CDN Indexing Router)
DEFINE TABLE knowledge_index SCHEMAFULL;

DEFINE FIELD user ON knowledge_index TYPE record<user>;
DEFINE FIELD collection_name ON knowledge_index TYPE string; -- Matches target RAG
collection
DEFINE FIELD document_title ON knowledge_index TYPE string; -- e.g., "Cloud Code
Concept"
DEFINE FIELD rag_document_id ON knowledge_index TYPE string; -- Direct lookup pointer
for vector DB
DEFINE FIELD cdn_url ON knowledge_index TYPE option<string>;
DEFINE FIELD descriptive_summary ON knowledge_index TYPE string;
DEFINE FIELD tags ON knowledge_index TYPE array<string>;
DEFINE FIELD keywords ON knowledge_index TYPE array<string>;
DEFINE FIELD created_at ON knowledge_index TYPE datetime DEFAULT time::now();

8. Key System Workflows
A. Lightweight Information Filtering & RAG Routing
To avoid resource exhaustion, incoming raw chat text is parsed through a small classification
helper within herandro-services-api:
1. Garbage Filtering: Trivial context ("I threw out the trash today") is filtered out entirely
unless explicitly flagged as a reminder.
2. Metadata Indexing: If significant facts or technical ideas ("Learned a new pattern for
Cloud Code") are shared, the text chunk is pushed to the RAG system, and its unique
reference router is indexed inside SurrealDB's knowledge_index table.
3. Fast Retrieval: When searching long-term data ("What did I say about Cloud Code last
week?"), the agent reads SurrealDB's structured indexes first, locating the precise RAG
collection/document block instantly instead of running an open vector query across a
massive, unstructured context footprint. If information isn't satisfied via the descriptive
summary index, it deep-dives into the full RAG data layer.
B. Dynamic Timing Resolution
When an agent parses a natural language command referencing fluid constraints (e.g., "Remind
me after the daily"):
● The agent invokes the query_user_facts internal tool using "daily" as a query parameter.
● SurrealDB matches fact_key = "daily_meeting_time" and returns the value "09:15".

● The agent interprets the exact execution time, updates the next_trigger_at timestamp,
and provisions the execution parameters directly into the persistent open-source task
broker.