Tiny Robot Lab Logo
Tiny Robot Lab Learning Project

Runtime Mechanics

How Tiny Robot Works

Every task submitted to the platform moves through an explicit, visible state machine rather than an undocumented prompt chain. Here is how capability discovery, availability evaluation, and evidence-conditioned research operate step by step.

Step-by-Step Flow

1. Capability-Driven Task Dispatch

In static systems, tasks are dumped into hardcoded worker queues. Tiny Robot Lab replaces static queues with dynamic candidate discovery and runtime availability checks.

The 7-Stage Dispatch Lifecycle

Platform Foundation
1 Prompt Input
2 Determine Capability
3 Candidate Discovery
4 Availability Check
5 Deterministic Routing
6 Target Dispatch
7 Execution & Result
  1. Prompt Input: An operator submits a natural-language task prompt via the Prototype Console or HTTP API.
  2. Capability Determination: The platform analyzes task intent and classifies the required capability (e.g., general or research).
  3. Candidate Discovery: The orchestrator queries registered agents to find all instances advertising support for the required capability.
  4. Availability Evaluation: Registered candidates are evaluated against liveness policies using heartbeat timestamps and execution state (distinguishing ready, busy, stale, and offline).
  5. Deterministic Routing: An eligible candidate is selected deterministically and an audit record of the routing decision is preserved.
  6. Target Dispatch: The task is dispatched to the chosen agent's dynamically advertised delivery target, with no assumed queue topology.
  7. Execution & Result: The agent consumes the task, emits operational state transitions over Redis, and records the final output.

Specialist Agent

2. Grounded Research Execution Pipeline

When a task requires research, asking an LLM to search and summarize in a single prompt invites hallucinations and opaque failures. The Research Agent breaks execution into discrete, observable stages.

Multi-Stage Evidence Pipeline

Research Agent
1 Public Web Retrieval
2 Candidate Evidence
3 Quality Evaluation
4 Conditioned Synthesis
5 Attributed Findings

How evidence is evaluated and retained:

  • Retrieval: The research query is sent to a web retrieval adapter (e.g., Tavily), returning raw search snippets and candidate URLs.
  • Candidate Evidence Normalization: Each snippet is structured with its source URL, page title, textual snippet, and provider relevance indicators.
  • Deterministic Evidence Evaluation: Before any generative LLM is invoked, pure Python domain logic scores evidence-ranking signals: domain authority tiers, topical keyword density, content length, and snippet freshness. Weak or irrelevant items are discarded.
  • Conditioned Synthesis: The inference model receives strictly the retained evidence items and is instructed to synthesize findings based exclusively on those sources.
  • Attributed Findings: The synthesized response includes structured source citations, allowing learners and operators to inspect which evidence drove each finding.
Important Distinction: Evaluated Evidence vs. Factual Truth
  • Evaluated evidence is not "verified proof." Our EvidenceEvaluator applies heuristic ranking signals (domain tier, keyword overlap, content length) to filter noise. It does not possess mathematical proof of factual accuracy.
  • Cross-domain keyword overlap is not semantic corroboration. Two independent websites sharing similar vocabulary may simply be repeating the same press release or common phrasing.
  • Retrieval quality is bounded by the provider. If the upstream retrieval API returns low-quality or irrelevant candidates, the downstream evaluation and synthesis cannot manufacture better source material.

Transparency

3. Observable AI in Practice

Every transition is visible. Instead of wondering why a task was routed to an agent or why a candidate was skipped, the orchestrator records the decision context.

Routing Decisions

Every task dispatch logs the resolved capability, the candidate pool evaluated, candidate availability states, and the deterministic reason for selection.

Heartbeat Liveness

Agents emit periodic heartbeat signals. Stale agents (>30s) and offline agents (>90s) are automatically disqualified from work without restarting services.

State & Event Streams

Operational events (idle, working, error) stream over Redis Streams and Hashes, powering the real-time activity timeline in the Prototype Console.