Mythos: a request that keeps its context

A personal agent system has to accept an unfinished thought and keep track of what it becomes. A voice note may be a reminder, a lookup or a coding request. Mythos brings those interactions into a coordination layer, with Telegram as a continuing human interface and Index providing execution infrastructure.

The bridge implementation makes the handoff concrete. Its job runner moves a request into triage, corrects the proposed plan where necessary, and dispatches to a capability-specific handler. This article examines that boundary in the available source, rather than claiming to describe every service in the larger Mythos installation.

Propose one capability

The primitive is a Plan containing a schema version, capability, arguments and confidence. The parser rejects unknown keys, unsupported schema versions and capabilities outside the known set. This gives the application a small vocabulary to reason about even when the original request is conversational.

extra = set(raw) - ALLOWED_KEYS
if extra:
    raise PlanError(f"unknown keys {sorted(extra)}")

if capability not in CAPABILITIES:
    raise PlanError(f"unknown capability {capability}")

Keep a state the person can understand

In _triage_and_run, a PlanError changes the job to needs_you and produces a Needs you response. A saved note takes another path: the handler records a capture, marks the job saved, and delivers a receipt. These states explain different outcomes instead of presenting every response as successful execution.

except PlanError as exc:
    log_event("triage.rejected", job_id=job_id, error=clip(str(exc)))
    self.store.update_job(job_id, status="needs_you", spoken="Needs you.", backend="triage")

A parser is one boundary among several

Correctly shaped data can still represent the wrong intent. The source includes a correction pass for coding requests that were proposed as notes, plus separate handlers for lookup, notification and execution. The interesting failures occur between those layers: an ambiguous request, an unintended backend, or a follow-up attached to the wrong piece of work.

A valid plan can still choose the wrong action. The parser verifies the plan format, while routing and follow-up handling have to preserve what the request meant. The Index note follows the receipt and Telegram reply stages.