# Tlamatini — Agent Descriptions > Latest released version: **[v1.92.4](docs/changes/2026-11-08-v1.92.4.md)**. ## Carried from v1.92.3 — Downloads, updates and build isolation Torrenter adds account-owned downloads to chat and the Agentic Control Panel. Live Editor and Terminater accept up to 250 WPM. The updater carries the uninstaller and preserves the vault. Release builds lease the Python environment for their requirements fingerprint. See the [v1.92.3 release record](docs/changes/2026-11-01-v1.92.3.md). ## v1.91.1 — Prompt Flow fixes and short tool names **v1.91.1** was the English release of that date (2026-10-27). Its annotated tag resolves to `9915938a` and was present on origin; it was published on GitHub as the then-Latest release, replacing v1.91.0 (published 2026-10-23). It is a patch release: no agent, tool, skill or migration was added, so the catalog stays **86 workflow agents, 67 wrapped chat agents, 110 built-in tools, 29 skills and 220 migrations**. - **Prompt Flow history:** every chain loads the history of the request's own `conversation_user_id`; a Prompt Flow run uses only its own in-memory history. - **YES/NO Decisions:** an `equals` Decision accepts an answer that opens with the value (`## YES - ...` equals `YES`; `Yesterday` does not), and the Prompt before it asks for that short answer alone on the first line. - **Usage:** a Prompt Flow run is recorded for the account that owns it. - **Telegrammer:** "using the bot ..." anywhere in the request (outside quoted values) sends as the bot; an explicit `provider` still wins. - **Short tool names:** a wrapped agent called by its short name (`terminater`) is resolved to `chat_agent_terminater` and logged as `[TOOL-ALIAS]`. - **Prompt Flow tab title:** an Untitled flow shows the name of its file. See the [v1.91.1 release record](docs/changes/2026-10-27-v1.91.1.md). ## Carried from v1.91.0 — Live Editor and Terminater configuration **v1.91.0** was the release of 2026-10-23. Its existing annotated tag resolves to `a771d27c` and is present on origin. The catalog remains **86 workflow agents, 67 wrapped chat agents and 110 built-in tools** (21 + 67 + 12 + 10), with **29 skills and 220 migrations**. The frontend has **64 JS modules and 29 CSS files** in the counted `static/agent/js` and `static/agent/css` directories. **Config → Live Editor & Terminater** opens one dialog with Live Editor, Terminater and Voice tabs, also available from the canvas and terminal Settings buttons on the chat and control-panel surfaces. Saved account preferences control real action pacing, teaching suggestions, shell defaults, manual Enter, waits and narration; editor/terminal appearance stays local to the account and browser. Presets and previews are drafts until Save; Stop, mute and tab access are immediate. Migration **0220** stores account preferences and revisions. One TerminalHub applies them across chat, ACP and Prompt Flow; legacy explicit flow values remain compatible. Speech uses the shared browser queue, selects one focused tab and can wait for a real completion receipt before typing. User interruption wins and private input is not narrated. The offline editor bundle and runtime/source carriers include the new UI and backend modules. Source evidence on October 23: **17/17 visible browser checks passed; 929 of 931 regression tests passed**, with two existing README documentation assertions failing before this documentation sweep. These are dated source results, not a new installed package acceptance. v1.91.0 was published on GitHub on 2026-10-23. See the [release record](docs/changes/2026-10-23-v1.91.0.md) and [settings guide](docs/interaction-settings.md). ## Carried from v1.90.0 — editable canvas and Interactor The v1.90.0 source line had **86 workflow agents, 67 wrapped chat agents, 110 built-in tools (21 direct/module + 67 wrapped + 12 ACPX/Skills + 10 supervisors), and 219 migrations** after migration 0219. Interactor added a module/tool, not an Agent. The annotated tag resolves to `ebc5c3b4` and its GitHub release was published on 2026-10-22. Later commits in that line carried the account wizard’s local Notifier checkpoints. This section preserves v1.90.0 history; current configuration and counts are described above. Dated source and frozen runs remain separate. - **Editor:** `agent_page_editing.js` owns the CodeMirror document, dirty baseline, encoding and save snapshot. `agent_page_canvas.js` owns load/refresh generation and cancellation. Markdown Preview and Source share the buffer; HTML/SVG remain inert source; PDF saving copies the original PDF. Never read a hidden compatibility element instead of the editor. - **Native files:** `canvas_file_views.py` and `native_dialogs.py` provide local Save As/read/save. Authentication, CSRF, loopback-only host access, account/session-bound capabilities and full revision checks prevent a browser name from becoming an arbitrary host path. Existing Windows replacement preserves metadata; DB backup/restore mechanics are unchanged. - **Interactor:** `agent/interactor/` connects the synchronous tool loop to the browser through session-authenticated `ws/interactor/`. Server-issued tab identity travels through ContextVar; bounded commands and receipts verify document/revision and full buffer. Browser messages acknowledge/access/stop; they cannot request arbitrary host-path commands. - **Tutor:** read fresh unsaved text, type a small segment, guide the next field and end mutations for the turn. Continue begins a fresh chat/read. Prepared choices match locally, with no per-key model call. User input and Stop win; hidden tabs pause with bounded recovery rather than repeating edits. - **Carriage:** migration 0218 seeds the Tool/catalog rows; `tool_gate_table()` supplies binding, Compact selection and cost labels. The offline editor bundle, Interactor browser files, frozen imports and source/static inventories must travel together. - **Intent:** password input is not ownership of every command; a wizard email field or DONE reply is not notification consent. Preserve genuine user-runs tutorials. The catalog wizard uses createsuperuser and therefore creates an administrative account. Contracts and evidence: [v1.90.0](docs/changes/2026-10-22-v1.90.0.md), [Canvas editing](docs/canvas-editing.md), [Interactor](docs/interactor.md), [Account wizard](docs/user-creation-wizard.md). Source/frozen rendering tests do not certify a rebuilt installed executable. This file is the **authoritative source of human-readable descriptions** for every workflow agent shown in the Agentic Control Panel sidebar of Tlamatini. The Django view `agent.views.agentic_control_panel` parses the table rows under `## Workflow Agents` below and injects the `Description` column into the page as `agent_purpose_map` JSON. The frontend (`acp-canvas-core.js`) reads that JSON and uses the text as the **hover tooltip** over each sidebar agent and as the **Description** dialog body when the user right-clicks an agent on the canvas. Editing a row's `Description` cell here changes both: - the documentation read by humans, AND - the live UI text displayed to end users. The lookup is case- and punctuation-insensitive: the key for each row is `re.sub(r'[^a-z0-9]+', '', name.lower())`. So "Kyber-KeyGen", "Kyber KeyGen", and "kyberkeygen" all resolve to the same description. Descriptions are written for **non-expert readers** — when in doubt, prefer the longer, friendlier phrasing over a terse one-liner. A user who has never seen the agent before should be able to understand **what it does, when to use it, and what its main inputs/outputs are** from a single tooltip read. --- ## Workflow Agents > **Note — the canvas PDF reader is not an agent.** Opening a PDF in the *chat* canvas and turning it into context (2026-09-16) is a page feature, not a workflow agent, so it has no row in this file: see [docs/pdf-canvas.md](docs/pdf-canvas.md). It does reuse the **Image-Interpreter** agent below for its optional image analysis, and it is distinct from **File-Extractor** (which extracts raw text from a PDF you name) and **PDFer** (which *creates* PDFs). The visual workflow designer ships with **87 agent types**, grouped below by their role in a flow. Drag any of them onto the canvas, wire connections between them, and press *Start* — the agents run as separate, log-emitting processes that talk to each other through their `config.yaml` files. ### Control Agents These agents shape the lifecycle of a flow: when it begins, when it ends, and what gets cleaned up afterward. | Agent | Description | |-------|-------------| | **Starter** | The entry point of every flow. When the user clicks *Start*, the Starter is the first agent that runs; its only job is to launch the agents listed in its `target_agents`. Think of it as the green "Play" button of the canvas — it does no real work itself, it simply kicks off the chain. | | **Ender** | Terminates a flow gracefully. Kills every agent listed in its `target_agents`, then launches anything wired into its `output_agents` (typically a FlowBacker for backups, followed by Cleaners that wipe transient files). Use Ender at the bottom of every flow that should shut down on its own. | | **Stopper** | A surgical "kill the noisy neighbor" agent. It watches the logs of one or more `source_agents` and, when a configured pattern appears (e.g. `FAILED`, `out of memory`), terminates exactly those source agents — without bringing the whole flow down. Stopper does NOT start downstream agents; it is purely a controlled-shutdown tool. | | **Cleaner** | The post-mortem janitor. After an Ender or FlowBacker completes, the Cleaner deletes the `.log` and `.pid` files of the agents it was wired to, returning the session pool to a clean slate. It is the only agent that should be wired AFTER Ender. | | **Sleeper** | A timed pause. Waits for a configured number of milliseconds, then starts everything in `target_agents`. Useful for rate-limiting polling loops, giving an external service time to settle, or building "every N seconds" cycles when paired with a Raiser. | | **Croner** | A clock-driven trigger. Wakes up at the configured `HH:MM` every day and starts its `target_agents`. Good for nightly backups, scheduled reports, or any "run this every day at 3 AM" flow. | ### Routing Agents These agents decide WHERE the flow goes next based on what they observe in upstream logs or user input. | Agent | Description | |-------|-------------| | **Raiser** | An event-driven launcher. Continuously watches the logs of its `source_agents` for a configured `pattern`. When the pattern appears, it fires every agent in `target_agents`. Raiser is the bread-and-butter bridge between *passive* monitoring agents and *active* action agents — anywhere you want "when X happens, do Y", a Raiser is the right answer. | | **Forker** | An automatic A/B router. Watches its source agents for two distinct sets of patterns (`pattern_a` and `pattern_b`); whichever set matches first determines which path the flow takes next (`target_agents_a` or `target_agents_b`). Use it whenever a single upstream signal can mean two different things and each meaning has its own downstream chain. | | **Asker** | An interactive A/B chooser. When it runs, it pops a dialog in the chat UI asking the user to pick Path A or Path B (with optional captions like "Approve" / "Reject"). The chosen path's `target_agents` are launched and the rejected path is left untouched. Has a 5-minute timeout. Perfect for human-in-the-loop approvals or a/b experiments. | | **Counter** | A persistent tally with threshold-based routing. Each time it runs it increments a stored counter and compares it against a `threshold_value`. If the counter is below the threshold it fires `target_agents_l` (less); if it has reached or passed the threshold it fires `target_agents_g` (greater). The count survives flow restarts via reanim files, so it can drive "do this 5 times then do that" loops. | ### Logic Gates These agents hold the flow until specific upstream conditions are met — they are pure synchronization primitives. | Agent | Description | |-------|-------------| | **AND** | A two-input AND gate. Fires its `target_agents` only when BOTH `source_1` AND `source_2` have produced their respective patterns. The match is *latched*: once a source matches, that side stays satisfied until the gate fires. Use it to require two parallel branches to both succeed before continuing. | | **OR** | A two-input OR gate. Fires its `target_agents` when EITHER `source_1` OR `source_2` produces its pattern, whichever happens first. Use it for "the first one wins" patterns, e.g. continue as soon as either of two redundant data sources finishes. | | **Barrier** | An N-input barrier (a generalized AND). Waits until ALL configured `source_agents` have started, then fires its `target_agents`. The first source to arrive becomes the polling watcher; every subsequent arrival drops a flag file and the gate releases when all flags are present. Designed for fan-in synchronization across many parallel branches without any race conditions. | ### Action Agents These are the agents that *do real work* — running commands, hitting APIs, producing files, calling LLMs, automating the desktop. | Agent | Description | |-------|-------------| | **Executer** | Runs an arbitrary shell command and triggers its `target_agents` when the command finishes. The command's stdout and stderr are captured to its log file. The simplest, most flexible "do something on this machine" agent — anywhere you would have typed a command into a terminal, an Executer can do it for you. **Preferred over Keyboarder / Mouser whenever a command or build step needs to run; never type a command into a terminal window through Keyboarder — give it to Executer instead.** | | **Pythonxer** | Runs an inline Python script (provided as a YAML string) behind a STRICT correctness gate: it first `compile()`-parses the script (an unparsable script is refused, never run) and then validates it with Ruff — when `ruff_blocking` is true (the default) any Ruff finding aborts execution with the findings logged. The script can use any installed package. **Downstream agents are ALWAYS triggered afterwards — no matter what (success, a gate refusal, or a runtime failure)** — so Pythonxer never dead-ends a flow; the exit code (0/non-zero) drives only the LED and the Multi-Turn fix-and-retry loop. Wire a downstream agent to inspect the result/log if a step must only proceed on success. An optional `execute_forked_window` flag opens the script in a new console for live stdout. Great for ad-hoc data wrangling, custom logic, or anything you'd write a one-off `.py` file for. **Preferred over Keyboarder / Mouser for code execution and computed-content generation; never drive Keyboarder to type Python into IDLE or an editor — feed the code to Pythonxer instead.** | | **SQLer** | Executes a Python block against a Microsoft SQL Server instance using `pyodbc`. The script receives `cursor` and `conn` as injected globals so you can write `cursor.execute("SELECT ...")` directly. Triggers downstream agents when the SQL completes successfully. Use it for ETL steps, schema checks, data exports, or anything that needs a real SQL session. | | **Mongoxer** | Executes a Python block against a MongoDB database using `pymongo`. The script receives a pre-connected `db` object so you can write `db.users.find({...})` directly. Triggers downstream agents on success. The MongoDB twin of SQLer — perfect for document-store reads, writes, and aggregations inside a flow. | | **Crawler** | A developer-oriented web reader with built-in LLM analysis. Fetches a URL via HTTP GET and captures **raw content by default** (full HTML, inline JS, CSS, headers, JSON-LD, data-* attributes, the lot) or plain text on demand, then sends it to an Ollama model with a developer-centric system prompt that produces a structured analysis. By **default it reads exactly the page you give it** (`crawl_type: page`); `small-range` walks that page's same-site links, `medium-range` every link, `large-range` recursively, each one analyzing the page itself first (`include_seed`). It is **block- and hang-proof**: every page has a hard wall-clock limit (`page_timeout_seconds`, 45 s) and a size cap, the whole run a deadline (`deadline_seconds`, 900 s) and a page cap (`max_pages`, 25). A bot wall, CAPTCHA, 401/403/429 or timeout comes back as `status: blocked` / `timeout` and never reaches the LLM as page content, and a crawl that analyzed nothing ends with one section that says NOTHING WAS ANALYZED and why. It does not run JavaScript: for a page built by JavaScript use Playwrighter. Outstanding for security audits, competitive analysis, or any "tell me what this page actually does" task. | | **Googler** | Performs block- and hang-proof indexed-web search, then either extracts readable text/raw HTML from the top results or returns only the hit URLs. The whole run obeys ONE wall-clock deadline (`deadline_seconds`, default 120) and every network call is bounded, so a stalled engine can never hold it. Tier 0 asks six server-rendered routes over plain HTTP in parallel (DuckDuckGo HTML/Lite, Bing, Mojeek, Brave, Yahoo); Tier 1 opens real installed Chrome with a persistent profile (`window_mode` visible/offscreen/headless; bundled Chromium fallback) across eight browser routes; Tier 2 answers from open knowledge sources (Wikipedia, arXiv, OpenAlex, Hacker News, GitHub, Internet Archive, Project Gutenberg) and says so. A relevance guard rejects poisoned answers (an engine replying off-topic), a refusal classifier names CAPTCHA/anomaly/rate-limit walls, and a shared health ledger rests refusing engines on a rising cooldown ladder instead of hammering them. `search_status` always tells the truth (ok, no_matches, blocked, unreachable or timeout), never a silent empty success. Its structured dork builder normalizes exact phrases, exclusions, dates, ranges, proximity, title/URL/text/anchor filters, discovery operators, and parenthesized uppercase-`OR` groups for multiple sites or file types. Presets cover books, lawful public/open books, papers, manuals, documents, slides, sheets, and directory listings; aliases such as `ebook`, `docs`, `code`, and `data` expand automatically, while explicit fields override preset defaults. Use `content_mode: links_only` for PDF/EPUB/file hunts, then pass URLs to Apirer/File-Extractor/File-Interpreter. Advanced date/proximity/range operators are Google-specific and may broaden on fallback engines; pin `engines: [google]` when exact semantics matter (an explicit list skips the plain-HTTP tier and the open sources). The direct Multi-Turn `googler` tool accepts manual operators in `query`, runs this same agent as a killable child that the user's Cancel stops, and reports a refusal as `Error: WEB SEARCH BLOCKED` instead of an empty answer; structured fields are the visual/pool surface. Googler finds public indexed URLs only, never solves a CAPTCHA itself (with `captcha_wait_seconds` a person may solve one in the visible window), never bypasses access controls, and leaves copyright, licensing, authorization, and use to the operator. | | **Playwrighter** | A scripted, interactive browser-automation agent built on Playwright (Chromium/Firefox/WebKit). Where Crawler does a static one-shot HTTP fetch and Googler only searches, Playwrighter drives a REAL browser through an ordered list of steps — navigate, fill forms, click, press keys, wait for elements, extract text/attributes, screenshot, assert, download — so it can log into a site, submit a multi-step form, click through a wizard, scrape a JavaScript-rendered single-page-app behind a login, or run an end-to-end UI check. Set `headless: false` to watch it drive, and `hold_open_seconds: N` (alias `hold_open_ms`) to keep the browser visible for N seconds after the last step before it closes (the "wait before closing so I can see it" knob); use `storage_state_in`/`storage_state_out` to carry a logged-in session between runs. It writes an `INI_SECTION_PLAYWRIGHTER` block (`status`, `assert_result`, extracted values) so a downstream Forker can branch on pass/fail and Parametrizer can pipe scraped data onward, and always triggers `target_agents` (success or failure). The visual-canvas counterpart of the `chat_agent_playwrighter` Multi-Turn tool. | | **Apirer** | An HTTP/REST API client agent. Performs a configurable GET / POST / PUT / DELETE request with arbitrary headers, body, and timeout, then logs the response status, body and round-trip latency in milliseconds. Authorization headers are masked in the log for security. Triggers downstream agents regardless of HTTP outcome (so retries and error branches are wired downstream, not inside the agent). | | **Kalier** | Tlamatini's bridge to **Kali Linux** offensive-security tooling, built on the MCP-Kali-Server (https://www.kali.org/tools/mcp-kali-server/). On trigger it POSTs to the MCP-Kali-Server Flask API (`server.py`) running on a Kali box and runs ONE capability selected by its `action` field: `nmap` (port/service scan), `gobuster` / `dirb` (web content & directory busting), `nikto` (web-server scan), `sqlmap` (SQL-injection testing), `wpscan` (WordPress scan), `enum4linux` (SMB/Samba enumeration), `hydra` (credential brute-force), `john` (hash cracking), `metasploit` (run a module), `command` (any shell command on the Kali box), or `health` (probe the API server and which tools are installed). It captures the tool's stdout/stderr into an `INI_SECTION_KALIER` block (`action`, `endpoint`, `subject`, `return_code`, `success`, `timed_out`, `server_url`) so a downstream Forker can branch on `{success}` / `{return_code}` and Parametrizer can pipe the output onward; it ALWAYS triggers `target_agents` (success or failure). Point `server_url` at the running API server (default `http://127.0.0.1:5000`; for a remote Kali box use an SSH tunnel `ssh -L 5000:localhost:5000 user@KALI_IP`, or set it to `http://:5000`). In **chat (Multi-Turn)** you never repeat the URL — Tlamatini is the embedded MCP-Kali-Server client and auto-injects the **`kali_server_url`** you set once in **Config ▸ URLs** as the default `server_url` on every `chat_agent_kalier` run (the LLM may still pass `server_url=` to override for a one-off box); on the canvas you set `server_url` in this node's dialog. Implemented self-contained with the Python stdlib (`urllib`), so it needs no extra packages in the agent pool. **Authorized use only — run Kalier ONLY against systems you own or are explicitly authorized to test (engagement, lab, CTF).** The visual-canvas counterpart of the `chat_agent_kalier` Multi-Turn tool. | | **Discoverer** | Tlamatini's bridge to the **ProjectDiscovery** security-tool suite (https://github.com/projectdiscovery) for recon, attack-surface mapping and vulnerability discovery. On trigger it runs ONE tool selected by its `tool` field: `subfinder` (passive subdomain enumeration), `httpx` (HTTP probe & fingerprint), `naabu` (port scan), `katana` (crawler/spider), `nuclei` (template vulnerability scan), or `cvemap` (CVE search — runs ProjectDiscovery's `vulnx`, since cvemap's own API was retired Aug 2025; filters `cvemap_severity`/`cvemap_product`/`cvemap_limit`) — plus the meta actions `bootstrap` / `validate` / `update_templates` / `list_tools`. It invokes each tool's own CLI DIRECTLY (no MCP server) like Kalier/ESP32er/Arduiner, self-contained on the Python stdlib. **ZERO-CONFIG**: on the first call it downloads a PRIVATE Go compiler into `/Go` and `go install`s the requested tool into `/Go/bin-tools` — no system Go, no PATH change (the first run is slow, then cached). It captures the tool's stdout + saved JSON into an `INI_SECTION_DISCOVERER` block (`tool`, `target`, `returncode`, `success`, `findings_count`, `json_path`, `pdcp_used`, `stage`) so a downstream Forker can branch on `{success}` / `{findings_count}` and Parametrizer can pipe results onward; it ALWAYS triggers `target_agents` (success or failure). The `pdcp_api_key` (ProjectDiscovery Cloud Platform) is OPTIONAL for every tool (it lifts cvemap's rate limit and enables nuclei's AI/cloud upload); subfinder reads its own `provider-config.yaml` for OSINT source keys. Set the PDCP key once in Config ▸ Access Keys Wizard ▸ 'Security Recon (ProjectDiscovery)' (auto-injected on every run; redacted from `.flw` exports and by `regen_secrets.py` before a push). `naabu` defaults to a CONNECT scan on Windows (no Npcap/admin needed); a fail-safe preflight REFUSES rather than mis-scan. **Authorized targets only** — subfinder/cvemap are passive, but httpx/naabu/katana/nuclei actively touch the target. The visual-canvas counterpart of the `chat_agent_discoverer` Multi-Turn tool. | | **Nmapper** | Tlamatini's LOCAL, **USE-ONLY** nmap bridge for pentesters / CTF recon. It runs a real `nmap` the user installed themselves — it **NEVER bundles or redistributes nmap** (nmap's NPSL forbids embedding it in a product without a paid OEM licence), so a scan only ever uses an nmap the user already has (resolved from PATH → `C:\Program Files\Nmap\nmap.exe` → a `%LOCALAPPDATA%\Tlamatini\nmap` copy). If none is found it REFUSES gracefully with install guidance, and `action='install'` (or `auto_install`) downloads + launches the OFFICIAL FREE nmap self-installer from nmap.org — the user's own download + admin install, which also brings Npcap. The DEFAULT is an UNPRIVILEGED TCP CONNECT SCAN (`-sT`) that needs NO Npcap and NO admin, so a fresh install scans immediately; raw-packet features (SYN `-sS` / OS-detect `-O` / UDP `-sU`) degrade gracefully on Windows without Npcap (auto-downgrade to a connect scan + a warning, never a crash). Pick ONE capability with `action`: `quick` (`-sT -sV -sC -Pn -T4 --top-ports 1000`, the CTF opener) / `full` (all 65535 TCP ports) / `top_ports` / `version` / `scripts` (targeted NSE) / `host_discovery` / `udp` / `custom` (safe base + validated `custom_args`; shell metacharacters rejected) / `validate` / `install`. It parses nmap's `-oX` XML + keeps the `-oN` report and emits an `INI_SECTION_NMAPPER` block (`action`, `target`, `scan_technique`, `ports`, `return_code`, `success`, `hosts_up`, `open_ports`, `npcap_present`, `xml_path`, `output_path`, `stage`) so a downstream Forker can branch on `{success}` / `{open_ports}`; it ALWAYS triggers `target_agents`. Direct-CLI sibling of Kalier/Discoverer, self-contained on the Python stdlib. **Distinct from Kalier** (a REMOTE Kali box via MCP-Kali-Server) and **Discoverer** (the ProjectDiscovery suite): Nmapper is the instant, zero-install LOCAL nmap. **AUTHORIZED TARGETS ONLY** — only scan hosts you own or are explicitly authorized to test (e.g. scanme.nmap.org). The visual-canvas counterpart of the `chat_agent_nmapper` Multi-Turn tool. | | **Unrealer** | Drives an Unreal Engine 5 editor instance through the Unreal MCP plugin's TCP protocol (default 127.0.0.1:55557 — the plugin must already be running inside UE5; the agent does not start the engine). Sends one JSON command per execution (`{"type": , "params": {...}}`) and captures the full Unreal response into an `INI_SECTION_UNREALER` block so Parametrizer can route specific fields into downstream agents. Forwards any command the connected plugin build exposes; the extended Unreal MCP surface is 53 commands across nine categories: actor manipulation incl. `focus_viewport` and `take_screenshot` (observe-your-change), Blueprint creation/editing incl. `set_pawn_properties`, Blueprint node-graph wiring incl. `find_blueprint_nodes`, input mappings, UMG widget building, **system** (`execute_python` — the universal in-editor escape hatch — plus `execute_console_command`, `get_class_info`, `list_assets`), **level/world** (`open_level` / `save_current_level` / `save_all` / `new_level` / `get_current_level`), **asset** (`import_asset` / `duplicate_asset` / `rename_asset` / `delete_asset` / `save_asset` / `create_folder`), and **material** (`create_material` / `create_material_instance` / `set_material_parameter` / `assign_material`). Headless build/cook/test is out of scope (that needs UnrealEditor-Cmd, not this editor socket). The visual-canvas counterpart of the wrapped `chat_agent_unrealer` Multi-Turn tool — same command surface, same response shape, fully unattended and chainable through Parametrizer. The recommended plugin to install is Tlamatini's own extended Unreal MCP fork — the Unreal Engine MCP modified specifically for this system — at https://github.com/XAIHT/XaihtUnrealEngineMCP.git (built on the upstream https://github.com/chongdashu/unreal-mcp; it ships the full 53-command surface). That same repo ALSO ships `scaffold_unreal_project.py`, which scaffolds a ready-to-open, ready-to-build **UE 5.8** C++ project (UnrealMCP pre-wired, **Visual Studio 2026** solution generated) from just a project name + directory — driven by the Catalog-of-Prompts entry `prompt-106`. | | **Blenderer** | Drives a Blender instance through the OFFICIAL Blender MCP add-on's TCP socket (default localhost:9876 — the add-on must already be running inside Blender with "Online access" enabled and the server started; the agent does not launch Blender). Unlike Unreal's verb-dispatch protocol, the Blender MCP wire format is a CODE-EXECUTION protocol — each run sends `{"type":"execute","code":,"strict_json":}` (NUL-framed) and Blender runs that Python (which assigns a `result` dict) — so Blenderer exposes a RICH ACTION CATALOG selected by its `command` field instead of forcing hand-written Python for every task: PASSTHROUGH `execute_code` (run arbitrary `bpy` Python — the universal escape hatch); READ-ONLY `ping` / `scene_info` / `get_objects` / `get_object_detail` / `blendfile_summary`; and MUTATING/OUTPUT `create_object` (cube/sphere/cylinder/cone/plane/monkey/torus), `delete_object`, `set_material` (Principled base colour), `screenshot`, and `render` (file outputs default under Tlamatini's Temp directory). It captures the full Blender response into an `INI_SECTION_BLENDERER` block (`host`, `port`, `command`, `status`, `error`, `response_body`) so a downstream Forker can branch on `{status}` and Parametrizer can pipe fields onward; it ALWAYS triggers `target_agents` (success or failure). Implemented self-contained with the Python stdlib (raw NUL-byte-framed socket), so the agent pool needs no extra packages. Because Tlamatini speaks the add-on socket DIRECTLY (no separate `blmcp` MCP-server bridge and no external LLM client), it is a drop-in, far more integrated alternative to the bare chat client blender.org recommends — with the full Tlamatini canvas, Multi-Turn, Exec Report and Parametrizer pipelines on top. The visual-canvas counterpart of the wrapped `chat_agent_blenderer` Multi-Turn tool. | | **STM32er** | Tlamatini's STM32 firmware agent — it programs the **WHOLE ST 32-bit line, from the Blue Pill (STM32F103) up through F7 / G0 / G4 / L0..L5 / H7 / U5 / WB**, via **two backends** chosen by `stm32_backend` (default `auto`). **(1) PlatformIO backend** (the broad, zero-config path): drives PlatformIO Core's `ststm32` platform **directly** (the ESP32er pattern — no MCP server), so a `board` (e.g. `bluepill_f103c8`, `nucleo_h743zi`, `disco_f407vg`) fixes the memory map/linker and one backend builds & flashes ~1000 STM32 boards; it auto-installs PlatformIO Core into the SHARED per-user dir ESP32er also uses, and `framework` defaults to `arduino` (stm32duino — a board-agnostic blink works everywhere) or `stm32cube` for bare HAL. **(2) Template-MCP backend** (STM32F407VG + rich serial/SWD HIL): drives the **STM32 Template Project MCP** (https://github.com/XAIHT/STM32TemplateProjectMCP) — a self-contained scaffold + MCP server that lets a flow **scaffold → author → build → flash → observe** STM32F4 firmware programmatically, with **no STM32CubeIDE GUI**, using the GCC / CubeProgrammer / HAL toolchain bundled inside STM32CubeIDE. Under `auto`, a `board` / a non-STM32F4 `device` / a PlatformIO-only action routes to PlatformIO; blank/F407 stays on the template MCP (zero regression). The newest silicon (STM32C0/H5/U0/WBA/N6) awaits the ST-native STM32CubeCLT backend (Phase 2/3) and is refused cleanly. **Zero-config**: STM32er DOWNLOADS and installs the MCP itself on first use (shallow `git clone`, or a GitHub-zip fallback when git is absent, then pip-installs `mcp`/`pyserial` if missing, then validates) into a per-user cache, so the user installs **only STM32CubeIDE + Tlamatini** — `action='bootstrap'` (re)provisions it explicitly. Before any compile/flash it runs a **safety preflight** that validates the arm-none-eabi-gcc toolchain / STM32CubeIDE / build tool / programmer / ST-LINK USB driver + a positively-confirmed connected probe / target device family, and **REFUSES (fail-safe)** rather than producing or uploading mis-targeted firmware — compile-only actions need NO board, but flash / erase / reset / serial / SWD / live-memory require a connected ST-LINK, and on the template-MCP backend a cross-family device is refused **and ROUTED to the PlatformIO backend** (whose own fail-safe preflight refuses only the newest silicon awaiting CubeCLT, flashes over the ST-LINK/SWD probe, and only WARNS on an inconclusive ST-LINK miss so a bare dongle is not false-refused); `action='validate'` reports the whole environment without building. On trigger it spawns that project's FastMCP **stdio** server (`mcp/stm32_mcp_server.py`), performs the MCP initialize handshake, and runs ONE capability selected by its `action` field, then captures the result into an `INI_SECTION_STM32ER` block (`action`, `tool`, `ok`, `returncode`, `success`, `project_dir`, `session_id`, `stage`, plus a `response_body` with the tool's stdout/stderr or JSON) so a downstream Forker can branch on `{success}` / `{returncode}` and Parametrizer can pipe `{project_dir}` (or live-memory samples) onward; it ALWAYS triggers `target_agents` (success or failure). The `action` covers all 23 MCP tools — environment (`get_config`, `discover_toolchain_tool`); project lifecycle (`create_project`, `write_source`, `read_source`, `list_sources`, `clean`); build & flash (`build`, `list_artifacts`, `flash`, `build_and_flash`, `erase`, `reset`); serial / VCP hardware-in-the-loop (`serial_list_ports`, `serial_connect`, `serial_send`, `serial_read`, `serial_disconnect`); and live SWD memory of a RUNNING target without halting it (`read_memory`, `write_memory`, `live_memory_start`, `live_memory_read`, `live_memory_stop`) — plus two composites that chain the stateful tools in one run: `serial_session` (connect → send/read → disconnect) and `live_monitor` (start → stream `monitor_seconds` → read → stop). A typical pipeline chains `create_project` → Parametrizer (carry `{project_dir}` forward) → `write_source` (drop generated `main.c`) → `build_and_flash` → a `live_monitor` / `serial_session` that proves the firmware runs on real silicon. Leave `server_script` **blank** for the zero-config auto-download (set it only to point at an existing local checkout — an on-disk path wins and skips the bootstrap); set `mcp_python` only if the Python running the server lacks the `mcp` / `pyserial` packages. On the canvas you set `stm32_backend` / `board` / `framework` / `environment` (PlatformIO) and `auto_bootstrap` / `mcp_repo_url` / `mcp_install_dir` / `preflight` / `device` in this node's dialog. In **chat (Multi-Turn)** you never repeat anything — Tlamatini auto-injects the **`stm32_mcp_server_script`** (default empty = bootstrap) plus optional `stm32_mcp_python` / `stm32_template_dir` / `stm32_ide_root` / `stm32_mcp_repo_url` / `stm32_mcp_install_dir`, **plus the SHARED `pio_executable` / `pio_core_dir`** (same globals as ESP32er), you set once in **Config ▸ URLs** on every `chat_agent_stm32er` run. Implemented self-contained with the Python stdlib (raw MCP stdio JSON-RPC over `subprocess`), so the agent pool needs no extra packages — only the server does. **Authorized hardware only — `flash` / `erase` / `reset` / `write_memory` mutate a real attached MCU.** The visual-canvas counterpart of the `chat_agent_stm32er` Multi-Turn tool. | | **ESP32er** | Tlamatini's bridge to **PlatformIO Core** (https://platformio.org) — the open-source embedded build system whose `pio` CLI lets a flow **scaffold → author → build → upload → observe** ESP32 (and ESP8266 / Espressif) firmware programmatically, with **no IDE**. Unlike STM32er (which drives a separate MCP server) PlatformIO already ships a complete CLI, so ESP32er invokes `pio` subcommands **directly** and captures their stdout/stderr. **Zero-config**: ESP32er DOWNLOADS and installs PlatformIO Core itself on first use (the official `get-platformio.py` installer, with a `pip install platformio` fallback) into a per-user cache, so the user installs **only the board USB driver + Tlamatini** — `action='bootstrap'` (re)provisions it explicitly. Before any build/upload it runs a **safety preflight** that validates `pio` is resolvable + a `platformio.ini` exists, and for an upload/monitor that a **serial port is actually connected** (ESP32 flashes over its onboard USB-serial bootloader — no external JTAG probe needed), and **REFUSES (fail-safe)** rather than running a build/upload that cannot succeed; `action='validate'` reports the whole environment without building. On trigger it runs ONE capability selected by its `action` field, then captures the result into an `INI_SECTION_ESP32ER` block (`action`, `tool`, `ok`, `returncode`, `success`, `project_dir`, `port`, `environment`, `stage`, plus a `response_body` with the `pio` stdout/stderr) so a downstream Forker can branch on `{success}` / `{returncode}` and Parametrizer can pipe `{project_dir}` onward; it ALWAYS triggers `target_agents` (success or failure). The `action` covers: environment/meta (`bootstrap`, `validate`, `system_info`, `boards`); project lifecycle (`create_project`, `write_source`, `read_source`, `list_sources`, `clean`); build & flash (`build`, `upload`, `build_and_upload`, `list_artifacts`); serial hardware-in-the-loop (`device_list`, `monitor` — a bounded `pio device monitor` drained for `monitor_seconds`, and `monitor_session` = upload → monitor in one run); and packages / QA (`pkg_install`, `pkg_list`, `pkg_update`, `check`, `test`). `create_project` scaffolds from the bundled **ESP32TemplateProject** (the ESP32 analog of Arduiner's ArduinoTemplateProject and STM32er's STM32 Template Project) — it copies the template, then stamps the requested `board` / `framework` into `platformio.ini`, so ONE template serves every ESP32 variant. **That copy is what makes the scaffold usable**: a bare `pio project init` leaves `src/` EMPTY, and under the Arduino framework the next `build` then fails to link (`undefined reference to 'setup'`), so a freshly scaffolded project would not compile. The template is a blink-and-print firmware (onboard LED + `LED ON`/`LED OFF` over serial at 115200 baud, with `BLINK_LED_PIN` / `BLINK_INTERVAL_MS` as `platformio.ini` build flags) verified to build clean on PlatformIO Core 6.1.19. A typical pipeline chains `create_project` (`board: esp32dev`) → Parametrizer (carry `{project_dir}` forward) → `write_source` (drop generated `src/main.cpp`) → `build` → `upload` → a `monitor` / `monitor_session` that proves the firmware runs on real silicon. Leave `pio_executable` **blank** for the zero-config auto-install (set it only to point at an existing PlatformIO binary — it wins and skips bootstrap). On the canvas you set `action` / `project_dir` / `board` / `framework` / `environment` / `port` (and `auto_bootstrap` / `pio_core_dir` / `preflight`) in this node's dialog. In **chat (Multi-Turn)** you never repeat anything — Tlamatini auto-injects the **`pio_executable`** / **`pio_core_dir`** you set once in **Config ▸ URLs** on every `chat_agent_esp32er` run. Implemented self-contained with the Python stdlib (`subprocess` + `urllib`), so the agent pool needs no extra packages. NOTE: the FIRST build downloads the espressif32 platform + toolchain (hundreds of MB) so it is slow. **Authorized hardware only — `upload` mutates a real attached MCU.** The visual-canvas counterpart of the `chat_agent_esp32er` Multi-Turn tool. | | **Arduiner** | Tlamatini's bridge to the **Arduino CLI** (https://arduino.github.io/arduino-cli/) — the official all-in-one tool whose `arduino-cli` binary lets a flow **scaffold → author → build → upload → observe** classic-Arduino / AVR / SAMD / Arduino-core firmware programmatically, with **no IDE**. The third microcontroller agent, it shares the ESP32er scheme: like PlatformIO's `pio` (and unlike STM32er's MCP server), arduino-cli is itself a complete CLI, so Arduiner invokes `arduino-cli` subcommands **directly** and captures their stdout/stderr. **The microcontroller is selected by the `fqbn`** (Fully Qualified Board Name, e.g. `arduino:avr:uno`, `arduino:avr:mega2560`, `arduino:samd:mkr1000`, `esp32:esp32:esp32`); the serial `port` and `baud` set the upload/monitor link. **Zero-config**: Arduiner DOWNLOADS and installs the arduino-cli binary itself on first use (the platform release archive from downloads.arduino.cc, unzipped into a per-user cache, then `config init` + `core update-index`), so the user installs **only the board USB driver + Tlamatini** — `action='bootstrap'` (re)provisions it explicitly. Because arduino-cli — unlike PlatformIO — does NOT auto-install platforms on compile, Arduiner **AUTO-INSTALLS the board's core** for the FQBN before a build (`auto_core_install`, default true); for THIRD-PARTY silicon (ESP32/STM32/RP2040) set `additional_urls` to the vendor's `package_*_index.json`. Before any build/upload it runs a **safety preflight** that validates `arduino-cli` is resolvable + a sketch (`.ino`) + an FQBN exist, and for an upload/monitor that a **serial port is actually connected** (Arduino-family boards flash over USB-serial — no external probe needed for the common path), and **REFUSES (fail-safe)** rather than running a build/upload that cannot succeed; `action='validate'` reports the whole environment without building. On trigger it runs ONE capability selected by its `action` field, then captures the result into an `INI_SECTION_ARDUINER` block (`action`, `tool`, `ok`, `returncode`, `success`, `fqbn`, `port`, `sketch_path`, `stage`, plus a `response_body` with the `arduino-cli` stdout/stderr) so a downstream Forker can branch on `{success}` / `{returncode}` and Parametrizer can pipe `{sketch_path}` onward; it ALWAYS triggers `target_agents` (success or failure). The `action` covers: environment/meta (`bootstrap`, `validate`, `system_info`, `boards`, `device_list`); cores & libraries (`core_update_index`, `core_search`, `core_list`, `core_install`, `core_uninstall`, `lib_update_index`, `lib_search`, `lib_list`, `lib_install`); project lifecycle (`create_project`, `write_source`, `read_source`, `list_sources`); build & flash (`build`, `upload`, `build_and_upload`, `clean`, `list_artifacts`); serial hardware-in-the-loop (`monitor` — a bounded `arduino-cli monitor --config baudrate=` drained for `monitor_seconds`, and the composite `monitor_session` = upload → monitor in one run). `create_project` scaffolds from the bundled **ArduinoTemplateProject** (the Arduino-family analog of STM32er's STM32 Template Project and ESP32er's `pio` scaffold) — it copies the template, renames the `.ino` to the destination folder, and stamps the FQBN/port into the template's `sketch.yaml` profile. A typical pipeline chains `create_project` (`fqbn: arduino:avr:uno`) → Parametrizer (carry `{sketch_path}` forward) → `write_source` (drop generated `.ino`) → `build` → `upload` → a `monitor` / `monitor_session` that proves the firmware runs on real silicon. Leave `arduino_cli_executable` **blank** for the zero-config auto-install (set it only to point at an existing arduino-cli binary — it wins and skips bootstrap). On the canvas you set `action` / `fqbn` / `sketch_path` / `port` (and `auto_bootstrap` / `arduino_cli_install_dir` / `auto_core_install` / `additional_urls` / `preflight`) in this node's dialog. In **chat (Multi-Turn)** you never repeat anything — Tlamatini auto-injects the **`arduino_cli_executable`** / **`arduino_cli_install_dir`** you set once in **Config ▸ URLs** on every `chat_agent_arduiner` run. Implemented self-contained with the Python stdlib (`subprocess` + `urllib` + `zipfile`/`tarfile`), so the agent pool needs no extra packages. **Authorized hardware only — `upload` mutates a real attached MCU.** The visual-canvas counterpart of the `chat_agent_arduiner` Multi-Turn tool. | | **ESPHomer** | Tlamatini's bridge to **ESPHome** (https://esphome.io) — the system that turns ESP32 / ESP8266 / RP2040 / BK72xx boards into smart-home devices from a **simple YAML config (NO C++)** — letting a flow **author → validate → compile → upload → observe** device firmware programmatically, with **no IDE**. Like ESP32er (PlatformIO) and Arduiner (arduino-cli), and unlike STM32er (which drives a separate MCP server), ESPHome ships a complete CLI, so ESPHomer invokes `esphome` subcommands **directly** and captures their stdout/stderr. **Zero-config**: ESPHomer INSTALLS ESPHome itself on first use (`pip install esphome`) into the agent's Python, so the user installs **only the board USB driver + Tlamatini** — `action='bootstrap'` (re)provisions it explicitly. Because the interactive `esphome wizard` can't run headless, ESPHomer ships a built-in **`new_config`** generator that writes a minimal, valid device YAML (a phone-controllable on/off light, with the native API / OTA / WiFi blocks) from `name` / `platform` / `board` / `wifi_ssid` / `wifi_password` / `led_pin`. Before any compile/upload it runs a **safety preflight** that validates `esphome` is resolvable + a device YAML exists, and for an upload/logs/run that a **serial port is connected** (first flash is over USB) **or** an OTA host is given in `port` (subsequent updates go over WiFi), and **REFUSES (fail-safe)** rather than running a build/upload that cannot succeed; `action='validate'` reports the whole environment without building. On trigger it runs ONE capability selected by its `action` field, then captures the result into an `INI_SECTION_ESPHOMER` block (`action`, `tool`, `ok`, `returncode`, `success`, `config_path`, `name`, `port`, `stage`, plus a `response_body` with the `esphome` stdout/stderr) so a downstream Forker can branch on `{success}` / `{returncode}` and Parametrizer can pipe `{config_path}` onward; it ALWAYS triggers `target_agents` (success or failure). The `action` covers: environment/meta (`bootstrap`, `validate`, `version`); device YAML lifecycle (`scaffold_template`, `new_config`, `write_config`, `read_config`, `config`, `clean`); build & flash (`compile`, `upload`, `run`, `list_artifacts`); serial/OTA HIL (`logs` — a bounded `esphome logs` drained for `monitor_seconds`); plus the one-call composite `scaffold_compile_upload` (author → config → compile → upload → logs in a SINGLE run). **`scaffold_template` copies the bundled ESPHomeTemplateProject** — two worked devices plus a shared `common/base.yaml` package, a `secrets.yaml.example` and a `.gitignore` — into `project_dir`; `new_config` and `scaffold_template` are complements, not rivals: generate when you already know the one device you want, scaffold when you want the surrounding structure to build on. The two sample devices are deliberately different shapes: `tlamatini-light.yaml` is **self-contained** (no `!include`, no `!secret`, copy it anywhere) while `tlamatini-sensor.yaml` shows the grown-up multi-device shape (`packages:` + `!secret`) using only on-board sensors, so it runs on a bare board with nothing wired to it. `new_config` also takes **`use_secrets`** (default **false**): true emits `!secret wifi_ssid` and writes the real credentials to a sibling `secrets.yaml` (never overwriting an existing one), which keeps the device YAML safe to publish — it defaults off because `!secret` is a custom YAML tag that a plain `yaml.safe_load` cannot read. A typical pipeline chains `new_config` → Parametrizer (carry `{config_path}` forward) → `compile` → `upload` → a `logs` that proves the device runs. Leave `esphome_executable` **blank** for the zero-config auto-install (set it only to point at an existing esphome binary — it wins and skips bootstrap). On the canvas you set `action` / `config_path` / `name` / `platform` / `board` / `port` (and `auto_bootstrap` / `preflight` / WiFi fields) in this node's dialog. In **chat (Multi-Turn)** you never repeat anything — Tlamatini auto-injects the **`esphome_executable`** you set once in **Config ▸ URLs** on every `chat_agent_esphomer` run. Implemented self-contained with the Python stdlib (`subprocess` + `glob`), so the agent pool needs no extra packages. NOTE: the FIRST compile downloads the platform + toolchain (via PlatformIO under the hood) so it is slow. **Authorized hardware only — `upload` mutates a real attached device.** The visual-canvas counterpart of the `chat_agent_esphomer` Multi-Turn tool. | | **Gitter** | A Git operations agent. Runs `clone`, `pull`, `push`, `commit`, `checkout`, `branch`, `diff`, `log`, `status`, or any custom git command against a local repository, capturing both stdout and stderr into a structured ` RESPONSE { ... }` block. Use it for unattended sync, CI-style builds that pull before they run, scheduled commits of generated artifacts, or audit trails of repository state. | | **Reviewer** | An LLM-powered code reviewer. On trigger it resolves a git diff for the configured `repo_path` — a commit range like `HEAD~1`, a branch like `origin/main`, or (with an empty `diff_ref`) your uncommitted working-tree and staged changes — then sends that diff to an Ollama model with a rigorous senior-engineer review prompt. It writes an `INI_SECTION_REVIEWER` block whose first field is a **verdict** (`APPROVE`, `REQUEST_CHANGES`, or `COMMENT`), followed by line-anchored findings spanning correctness, security, performance and readability. Because the verdict is a header field, a downstream Forker can branch the whole flow on it — e.g. auto-merge on APPROVE, open an issue on REQUEST_CHANGES. The visual-canvas counterpart of the `code-review` skill. | | **Analyzer** | A deterministic static-analysis and security scanner — it uses no LLM, so its output is reproducible. On trigger it runs whichever of `bandit`, `semgrep`, `ruff`, `eslint`, `gitleaks` and `pip-audit` are installed on PATH over the configured `target_path`, aggregates their findings, and writes an `INI_SECTION_ANALYZER` block whose `status` is `clean`, `findings`, or `error` and whose `total_findings` count lets a downstream Forker gate the flow (for example, block a deploy when secrets or high-severity issues are found). Scanners that aren't installed are listed as skipped rather than failing the run. The visual-canvas counterpart of the `security-audit` skill. | | **SSHer** | Runs a shell command on a remote host over SSH using a pre-configured key. Captures stdout and stderr and triggers `target_agents` on success. The "Executer for somebody else's box" — pair it with SCPer to push a script first and then run it remotely. | | **SCPer** | Transfers a file to or from a remote host over SCP using a pre-configured SSH key. Direction is either `send` (local → remote) or `receive` (remote → local). The file-transfer companion of SSHer; together they cover almost every "do something on the staging server" scenario. | | **Dockerer** | A Docker / docker-compose front-end. Runs `up`, `down`, `restart`, `stop`, `build`, `logs`, `ps`, `pull`, etc. against a configured `compose_file` or against the local Docker daemon. Use it to spin a container up before a test runs, stream logs into a flow, or tear down environments at the end of a run. | | **MCP Doctor** | A safe External MCP diagnostic and onboarding agent. It reads the preserved/sanitized `external_mcps.json` catalog, normalizes common client shapes, detects stdio/HTTP/SSE/WebSocket and diagnosed future transports, infers Docker/Node-npx/uvx/Python/Java/.NET requirements, checks Tlamatini's private runtime plus system locations, treats a missing managed Node/uv tool as provisionable rather than fatal, flags placeholder secrets without revealing values, and emits `INI_SECTION_MCP_DOCTOR` for Parametrizer/Forker flows. Use it before activating an unknown MCP; shipped `memory` and `sequential-thinking` are official inactive defaults, not automatic authority to run them. | | **Instant Messaging Doctor** | A safe first-party messaging diagnostic agent for **Telegrammer** and **Whatsapper**. It validates contact-book resolution, readable Telegram `@username` routing, official Telegram Bot API/user-session readiness, official Meta WhatsApp Cloud API token/phone-number/template/webhook readiness, message policy blockers, and selected failure-log excerpts. It can run directly in Multi-Turn (`chat_agent_instant_messaging_doctor`) or automatically after a Telegrammer/Whatsapper failure, emits `INI_SECTION_INSTANT_MESSAGING_DOCTOR` (`platform`, `status`, `telegram_status`, `whatsapp_status`, `contact_status`, `repair_status`, `retry_status`, `actions_required`, body=`response_body`), and can ask Ollama (`deepseek-v4.1-flash:cloud` by default) for a compact operator summary. It never substitutes Twilio, TextMeBot, or another relay; Whatsapper's separately selected `provider=web` route remains an explicit, unofficial operator choice rather than a Doctor fallback. | | **Kuberneter** | A `kubectl` front-end. Runs commands like `get`, `apply`, `logs`, `exec` against a configured namespace, with arbitrary extra arguments or a fully custom command line. Its structured result keeps the numeric process result under `returncode`, adds explicit `success`, and reserves `status` for the closed `ok`/`failed` verdict vocabulary, so a failed kubectl command cannot silently default to a green Exec-Report row. Lets a flow inspect, deploy to, or debug a Kubernetes cluster as a normal step in your canvas. | | **PSer** | An LLM-powered process finder. Given a `likely_process_name` (e.g. "vscode" or "the python that runs my web server"), it lists running processes and asks an Ollama model to identify the best semantic match. Useful when an automation needs to react to "the user's editor" or "their dev server" without knowing the exact binary name in advance. | | **Jenkinser** | Triggers a job on a Jenkins server. Handles the CSRF crumb dance, posts build parameters, logs the response, and starts downstream agents regardless of trigger result. Use it inside any flow that needs to nudge a CI pipeline (e.g. "after my commits land, kick the deploy job"). | | **Prompter** | Sends a configured prompt to an Ollama LLM and logs the response into a structured `INI_SECTION_PROMPTER` block. This is the simplest "ask the local LLM something" agent — use it for one-shot generation steps that downstream agents can then parse, or as the LLM-side of a Parametrizer chain. | | **Summarizer** | Two modes in one agent. **Polling mode**: continuously watches the logs of its `source_agents` and feeds new content to an Ollama model with a configurable system prompt; when the LLM detects a positive event (writes `[EVENT_TRIGGERED]`), it fires `target_agents`. **One-shot mode** (when `input_text` is provided directly): summarizes that text once with a target word count and emits a single `INI_SECTION_SUMMARIZER` block. Pair it with File-Interpreter or Crawler to compress long content into something a downstream agent can act on. | | **File-Interpreter** | Reads and interprets documents — DOCX, PPTX, XLSX, PDF, TXT, TeX, CSV, HTML, RTF, and more — extracting text and (optionally) embedded images. Three reading modes: `fast` (text only), `complete` (text + images dumped to a sibling `images/` folder), and `summarized` (text + LLM-generated summary). Outputs neatly structured INI/END_FILE blocks per file. Wildcards are supported, so a single agent can process an entire folder of documents in one run. | | **File-Extractor** | The "give me the raw text" sibling of File-Interpreter. Reads a path or wildcard pattern, extracts plaintext using the same multi-format support, and falls back to a `strings`-style scan for unknown binary types. No LLM, no summarization, no image dumping — just text. Ideal as the first hop in a pipeline that ends in Parametrizer → another agent's `buffer` field. **Claude-Read-style VIEW options** (all optional, default to the full text): `line_numbers` prefixes each line with its 1-based file line number; `offset` (1-based start line) + `limit` (max lines) return just a slice - read lines 200-260 of a big file without dumping the whole thing. | | **Image-Interpreter** | TRIPLE-MODEL vision analyst. For each image it runs TWO interpreters IN PARALLEL, each on its OWN dedicated Ollama connection — `interpreter_model_1` (default mistral-large-4:cloud, forensic OCR/measurement: every mockup/GUI element with position %, size %, colors, fonts, verbatim text) and `interpreter_model_2` (default gemma4:cloud, holistic context: design intent, people, identity hypotheses) — then a BARRIER waits for BOTH interpretations, and `merging_model` (default deepseek-v4.1-flash:cloud) fuses them into ONE definitive report logged as a structured `INI_SECTION_IMAGE_INTERPRETER` block (`file_path`, `interpreter_model_1/2`, `merging_model`, `status`, body = merged report). The image FILE NAME is injected into all four prompts (`prompt_user` + the three engineered per-model prompts) as an identity clue. Accepts wildcards, a directory, a File-Interpreter pool name, or a single file. Supports 12+ image formats (JPG, PNG, GIF, BMP, TIFF, WebP, SVG, ICO, HEIC, AVIF). The eyes of any flow that needs to look at screenshots, mockups, charts, or photos. **Since 2026-09-16 it is also the engine behind the chat canvas's PDF reader**: when you open a PDF in the canvas, press *Use as context* and tick **Process images**, every rendered page preview and every embedded image is analysed by this same agent, through its own saved configuration, with a PDF-specific prompt asking for OCR, chart/table/diagram interpretation and explicit uncertainty. It is **reused, not duplicated** — its pipeline builder was made import-safe so the PDF backend can call it directly, while running `image_interpreter.py` as a pool agent still performs its original logging, working-directory and process setup exactly as before. Partial and failed analyses are recorded per image rather than hidden, so a PDF report can honestly say which images it could not read. | | **Video-Analyzer** | Video-Analyzer supports `analysis_type: robotics` (default), `transcription`, and `summary`. Robotics preserves the deterministic motion gate and dual-vision/merge verdict, with `PASS_OK` only on two explicit independent passes. Transcription reads selected video audio tracks (`audio_tracks: all` or `0,1`) using Whisperer's local faster-whisper backend, GPU auto/CPU fallback and timestamped segments; it never opens a microphone. Summary combines speech with two independent visual observers over frame batches spanning the whole clip, then synthesizes an overview, chronology, readable screen text, facts, steps, decisions, action items and limitations. Content modes accept static scenes, bypass the motion gate, and emit `TLM_ANALYSIS::` tokens rather than robotics verdicts. Missing audio/speech and partial failures are explicit. Each content run saves transcript, segments, report and full analysis artifacts. Parametrizer and wrapped chat results expose `analysis_type`, `analysis_token`, `transcript`, `summary`, `audio_status`, timestamped `segments_json` and artifact paths; the body remains `response_body`. Input remains a file, wildcard, newest video in a folder or Camcorder pool name, or a web link (YouTube and other sites): Video-Analyzer downloads it itself (one item; sound only for transcription), joins picture and sound with PyAV when ffmpeg is absent, keeps a self-updating private yt-dlp, names every download failure, and adds `source_url`/`source_title` to its result. Always starts downstream agents; sampled perception is not exhaustive. | | **NetSpeed-Calculator** | Measures THIS machine's real Internet connection and reports the answer **with its error bar** — download, upload, latency, jitter, packet loss and **bufferbloat** — following RFC 6349 (TCP throughput) and RFC 3550 §6.4.1 (jitter) against SEVERAL keyless public providers at once (Cloudflare, Ookla/Speedtest, Fast.com/Netflix Open Connect, LibreSpeed, Hetzner, CacheFly — no API key, no login, no account). Per provider it opens `parallel_streams` concurrent TCP flows in each direction, **DISCARDS the slow-start ramp** (`warmup_seconds`), samples **d(bytes)/dt** every `sample_interval_seconds` rather than the naive total÷elapsed, rejects outliers with Tukey IQR fences, then takes a trimmed mean and a Student-t interval. The providers are then FUSED by a **DerSimonian-Laird random-effects meta-analysis** publishing a 95% confidence interval and an **I² heterogeneity** figure — so when CDNs genuinely disagree the interval widens on purpose instead of one flattering number winning. Bufferbloat is measured as the RTT *increase under load* and graded **A+ → F**, which is what actually explains choppy calls on a "fast" link. Endpoint discovery is live and self-healing: Ookla and LibreSpeed servers are chosen by **measured RTT** (geography is a proxy for network distance, never a substitute), Cloudflare's object size is clamped below the size it rejects with HTTP 403, and a provider whose endpoint moved or died is skipped with a NAMED reason rather than silently reporting `0.00 Mbps`. Every failed transfer says WHY, in the log and in the saved result — a silent zero looks exactly like a slow link and sends the user hunting a fault in their own house. Emits an `INI_SECTION_NETSPEED_CALCULATOR` block (`action`, `status`, `success`, `providers_attempted/ok/failed`, `download_mbps`, `upload_mbps`, the CI95 fields, `latency_ms`, `jitter_ms`, `packet_loss_pct`, `bufferbloat_ms`, `bufferbloat_grade`, `aggregation`, `heterogeneity_i2`, `samples`, `isp`, `client_ip`, `server_location`, `json_path`, `stage`; body = the full human report) and ALWAYS triggers `target_agents` — success, partial or refusal — so a downstream Forker can branch on `{success}` or `{bufferbloat_grade}`. A fail-safe preflight REFUSES rather than publish a number it cannot trust. **⚠️ Consumes real, possibly metered bandwidth (~100-200 MB per full run)**, which is why it is gated by Ask-Execs. The visual-canvas counterpart of the `chat_agent_netspeed_calculator` Multi-Turn tool. | | **J-Decompiler** | A Java decompiler. Scans a directory (or wildcard list) for `.class`, `.jar`, `.war`, and `.ear` files and uses the bundled `jd-cli` tool to generate human-readable Java sources next to each artefact (or into sibling directories for archives). Use it to inspect third-party JARs, recover sources from build artefacts, or audit obfuscated code. | | **De-Compresser** | Deterministic short-running archive worker. Direction is inferred from the extensions: if `input` is a `.gz`, `.7z`, `.zip`, `.tar.gz`, or `.gz.tar` file the agent **decompresses** into the `output` directory; if `output` ends in one of those extensions the agent **compresses** `input` (a file or a directory) into `output`. Handles GNU Zip (`.gz`), universal ZIP (`.zip`), LZMA/LZMA2 7-Zip (`.7z`) and gzipped tar (`.tar.gz` / `.gz.tar`). Password handling: set `passwordless=true` to skip; set `passwordless=false` and the agent reads the password from the OS environment variable `DE_COMPRESSER_PWD` — if that variable is undefined the agent fails fast and still triggers any `target_agents`. Use it whenever the user wants to pack/unpack files inside a flow without dropping into `chat_agent_executer` + `tar`/`zip` CLIs. | | **Mover** | Moves or copies files with wildcard sources, exclusions, and optional recursion. In v1.48.13, empty, relative, and legacy `C:/Temp/...` scratch destinations are resolved beneath Tlamatini's application-owned `/Temp`; an explicit absolute destination supplied by the user remains authoritative. Use it to herd outputs, archive logs, or stage artifacts without scattering implicit scratch files at the drive root. | | **Deleter** | Deletes files matching one or more patterns, with exclusions, recursion, and immediate/event modes. **`target_path` is the working directory (never itself a delete target)** — relative targets resolve against it, so it never deletes the folder you point it at. Deleting a whole directory tree requires `allow_directory_delete: true`, and a safety guard refuses protected application directories, the working directory or an ancestor, git roots and drive roots. Its defaults and examples follow the same application-owned `/Temp` policy as Mover, and normalization never broadens the requested pattern, parent directory, or recursive deletion scope. | | **File-Creator** | Writes a file with arbitrary content to a specified path, then triggers downstream agents (regardless of the write outcome). The content is taken verbatim from the YAML config, so you can use it to write JSON, scripts, fixtures, prompt templates — anything. Often the last step of a Parametrizer chain that materializes an LLM-generated artefact onto disk. **Preferred over Keyboarder / Mouser for ALL source-file / script / config authorship; never open Notepad / VS Code / an IDE and type the file through Keyboarder — File-Creator writes the file atomically in one step.** Set `append: true` to ADD the content to the end of an existing file instead of overwriting it (the file is created if it is missing). | | **Shoter** | Captures the whole desktop by default (`all_screens: true`) and saves a PNG silently. Reports the image path plus physical capture origin, dimensions, timestamp, and monitor geometry when available. These fields let Mouser map image coordinates accurately, including resized images and monitors left of the primary display. Pair with Image-Interpreter for visual analysis; a screenshot alone does not identify a control. Read-only/observational and included in the Exec Report. | | **Globber** | Read-only FILE discovery by glob/filename pattern under a directory (the Claude-Glob equivalent) - returns matching file paths, newest-first by default. Pass `pattern` (a glob like `*.py` or `**/*.md`; `**` searches recursively; brace sets like `**/*.{js,py}` and lists like `*.py,*.js` work too) and `path` (the base directory); optionally `sort_by` (`mtime` = newest modified first [default], `name` = alphabetical, `none`) and `max_results` (cap, default 500). Returns files only (not directories) and never changes anything. Emits an `INI_SECTION_GLOBBER` block (`pattern`, `path`, `matches`, `truncated`, `status`) and ALWAYS triggers `target_agents` so a downstream Forker can branch on `{status}`. Use it to DISCOVER which files exist or were recently changed before reading, grepping, or editing them. The visual-canvas counterpart of the `chat_agent_globber` Multi-Turn tool. | | **Grepper** | Read-only regex CONTENT search across a single file or a whole directory tree (the Claude-Grep equivalent) - returns matching lines as `file:line:match`. Pass `pattern` (a Python regex) and `path` (the file or directory to search); optionally `glob` (a file filter: `*.py` matches file names, `src/**/*.py` matches paths below `path`, and brace sets or lists like `*.{js,py}` or `*.py,*.js` work too), `case_insensitive`, `output_mode` (`content` = file:line:match lines [default], `files` = matching paths only, `count` = per-file counts, `lines` = READ one file VERBATIM), and `max_results` (cap, default 200). **`output_mode: lines` needs NO pattern** and is the raw-read capability the agent pool previously lacked - File-Interpreter interprets through an LLM, File-Extractor extracts from binary containers, and the search modes all require a regex, so getting the exact bytes of a region meant leaving Tlamatini for a shell `type`/`sed`. Give it `start_line` / `end_line` (1-based, INCLUSIVE; `0` = from the first line / to the last) and `line_numbers`: `false` returns the exact text of the slice - and because ⚠️ the LOG is not a byte-exact channel (Python's logging handler turns every "\n" into "\r\n" on Windows, so a CRLF file would come back CR-CR-LF), so the exact bytes ride a base64 side-channel instead: `line_numbers: false` also emits **`content_b64`**, and DECODING that is what gives a truly byte-exact Editor `old_string`. The readable body is for humans; `content_b64` is for machines. `true` (the default) prefixes each line `N: ` for navigation and emits no `content_b64`. A directory is REFUSED (`status: refused`) rather than guessed at; use Globber to choose the file first. Noise directories (.git, node_modules, venv, __pycache__, dist, build) are pruned. Its BOM-first reader searches UTF-8, UTF-16/32, cp1252, and Latin-1 text, testing a BOM before NUL bytes so PowerShell logs and accented Windows/Spanish sources are not misclassified as binary; genuinely binary or unreadable files are still skipped. Never changes any file. Emits an `INI_SECTION_GREPPER` block (`pattern`, `path`, `glob`, `matches`, `files_searched`, `truncated`, `start_line`, `end_line`, `lines_returned`, `total_lines`, `status`) and ALWAYS triggers `target_agents` so a downstream Forker can branch on `{status}`. Use it to FIND where something appears, then to READ that region back verbatim before editing it - `Grepper(content) -> Grepper(lines) -> Editor` is the canonical surgical-edit chain, with no shell step anywhere in it. The visual-canvas counterpart of the `chat_agent_grepper` Multi-Turn tool. | | **PDFer** | Document composer for an answer, Markdown, HTML, plain text, images or existing PDFs. Modes: `auto`, `markdown`, `html`, `text`, `images`, `mixed`, `merge`, `info`, `validate`, `styles`; `styles` returns the 24-style catalog with `status: inspected` and no PDF, `info` inspects an existing PDF, and `validate` probes backends. **24 visual identities in five families** — playful/nursery, cyberpunk, cosmic, electronics and Tlamatini — are selected explicitly with `style`, alongside the **20 semantic themes** selected by `nuance` or content detection. `style: auto` preserves automatic styling; an unknown style falls back to the semantic theme with a diagnostic. Exact aliases include `cute`, `baby`, `space`, `electronics`, `aztec` and `alien`. `predominant_color` recolors the palette; per-role colors, font and page controls remain available. Original vector cover art respects the semantic decoration ceiling; legal, clinical and financial documents receive no ornament. The atelier renderer measures tables and cover text, wraps long tokens without changing their characters, continues long titles/subtitles on later pages, and checks small text against the normal contrast floor. With `layout_audit: true` (default), it reopens the finished atelier PDF and reports overlap, off-sheet, blank-page and contrast findings. `status: created` confirms file creation, not a clean audit; blank `layout_clean` means no available audit, `overlaps: 0` does not rule out other findings, and `repairs` lists solver actions rather than certifying success. `engine: auto` uses atelier unless custom `css` selects the legacy path. Styles do not restyle legacy CSS, image-only layouts or existing merged pages. Page controls include title/subtitle/author, A4/Letter/Legal/A3/A5/Tabloid, orientation, margins, cover, TOC and footer; `document_language` localizes PDFer's own labels without translating source text. Optional `ollama_polish` and `ollama_design` remain off by default and fall back if unavailable. Uses the already bundled libraries and host fonts. Saves to `Documents/TlamatiniPDF` or `output_dir` with collision-safe names; preflight checks inputs, engines and destination. Emits `INI_SECTION_PDFER` with `mode`, `source_type`, `output_path`, `output_dir`, `filename`, `page_count`, `bytes`, `images_used`, `engine`, `nuance`, `nuance_confidence`, `nuance_source`, `style`, `style_family`, `palette`, `predominant_color`, `background_mode`, `font_pairing`, `decorations`, `overlaps`, `layout_clean`, `repairs`, `status`, plus `response_body`. Parametrizer can carry style and color into another document; Forker can branch on status and audit results. Always triggers `target_agents`; captured in the Exec Report and still on Ask-Execs tier A. Canvas counterpart of `chat_agent_pdfer`. [Complete style guide](Tlamatini/agent/agents/pdfer/STYLES.md). | | **PPTXer** | Builds editable PowerPoint presentations from an answer, Markdown, outlines, or JSON, with embedded local/remote images, video/audio, tables, charts, diagrams, and generated artwork. **36 named treatments = 24 automatic content treatments + 12 explicit visual styles**, selected through `nuance` (for example, `blueprint` or `botanical`); empty retains automatic classification. **17 font pairings** resolve against installed fonts. Measured layout accounts for font variants, spacing, insets, and complete long text; dense cards/tables/columns continue across slides. The 256-character stress cases are validation inputs, not a content limit. Audits inspect saved geometry, grouped/table text, native PowerPoint bounds, and sampled contrast; inspect `status`, `layout_clean`, `ground_truth`, and report confidence before distributing. `created_with_findings` requires review even when `success: true`; `render`/`audit` report `ok` or `findings`. Missing audit results do not establish a clean deck. `ground_truth` identifies native rendering; check slide coverage, skipped measurements and audit errors before claiming full verification. `render: auto` tries PowerPoint, LibreOffice, then an approximate Pillow preview; Office is optional for creation. `render: none` skips images while `layout_audit: true` still measures geometry. Atomic output saves protect existing files; the bounded Office worker cleans up only its own attributable processes. Actions: `create`, `outline`, `render`, `audit`, `info`, `fonts`, `validate`. `outline`/`info`/`fonts` return `listed`; `validate` returns `validated`; none creates a new deck. Styles use `nuance`, with no separate `style` parameter or style-catalog action. `INI_SECTION_PPTXER` exposes the action/status, output paths, content counts, theme/font metadata, render/audit fields and `response_body` for flow routing. Report omitted media when it is required by the user; creation alone does not guarantee every asset was embedded. Default output: `Documents/TlamatiniPPTX`; always starts configured downstream agents, including on refusal. [Styles, controls, and verification](Tlamatini/agent/agents/pptxer/STYLES.md). | | **LaTeXer** | Tlamatini's LaTeX TYPESETTING agent — the typesetting sibling of PDFer. PDFer *composes* a PDF out of Markdown, HTML and pictures; **LaTeXer *typesets* one from real `.tex` source**, which is what you want when the document needs proper mathematics, a bibliography, numbered cross-references or an index. **PDF compilation needs a TeX distribution; MiKTeX is recommended.** Tlamatini does not ship a TeX distribution (a full one is several gigabytes and the release must stay small), so install **MiKTeX** once from **https://miktex.org/download** to compile PDFs locally. MiKTeX is the recommended distribution for one concrete reason: when a document asks for a LaTeX package you have never installed, **MiKTeX downloads and installs it by itself, in the middle of the build**, so the document still comes out. (TeX Live and MacTeX are also detected; the repair ladder can attempt package acquisition through their available `tlmgr`.) If no LaTeX is installed, compilation says so plainly and refuses — it never crashes and never pretends a PDF was made; `action: install` will even download and launch the official MiKTeX installer for you. Pick what it does with `action`: `compile` (the usual one — hand it `input_text` with your LaTeX, or a `tex_path`, or a `project_dir`), `compile_project` (a whole SET of `.tex` files — it finds the master document for you and follows every `\input`), `scaffold_compile` (template → PDF in one go), `create_file`, `create_from_template` (article, report, book, beamer, letter, cv, homework, spanish-article), `edit_file`, `read_file`, `list_files`, `validate_tex` (a syntax check that needs no LaTeX installed at all), `structure`, `clean` (removes the `.aux`/`.log` clutter — never your `.tex` or `.pdf`), `validate`, `install` and `list_styles` (the 30-style catalogue, with no TeX probe). You can hand it a bare fragment — even just `$E = mc^2$` — and it wraps it in a proper preamble for you. It runs the compiler as many times as LaTeX actually needs, with `biber`/`bibtex`, `makeindex` and `makeglossaries` in between, until the references settle; then it turns the famously unreadable LaTeX log into a short list of real errors, and tells you which package was missing. Choose `engine` (pdflatex, xelatex, lualatex) and `document_language` (`en`/`es`). Finished PDFs land in your **Documents/TlamatiniLaTeX** folder with a collision-proof timestamped name, or wherever `output_dir` says; scaffolded projects go under Tlamatini's Templates folder. `shell_escape` stays OFF by default on purpose — it would let a `.tex` file run arbitrary commands on your machine. It emits an `INI_SECTION_LATEXER` block (`action`, `engine`, `distribution`, `tex_path`, `project_dir`, `output_path`, `output_dir`, `filename`, `page_count`, `bytes`, `passes`, `bibliography`, `errors`, `warnings`, `success`, `status`, `style`, `style_family`, `style_mode`, `style_count`; body = `response_body`) so a downstream Forker can branch on `{status}` or `{success}`; it ALWAYS triggers `target_agents`. If a build fails it does not simply give up: an **eight-rung repair ladder** escalates through lint repair, inferred preamble packages, deterministic rewrites, log-directed fixes, package acquisition, an engine swap (xelatex / lualatex), an optional AI repair pass, and — only as a true last resort — quarantining the offending block and building the rest. `repair: true` enables the ladder; `repair_rungs: []` enables all eight. Repairs normally build from a `.latexer-fixed.tex` copy (`repair_write_back: false`), and a model rewrite that still fails compilation is discarded. The model rung is configured by default; `repair_model: ""` disables it. `repair_model_timeout: 600` bounds that consultation; `command_timeout: 600` applies per tool invocation, not to the whole ladder. `repair_bisect_max_probes: 14` bounds last-resort probes. If a PDF exists only because blocks were removed, `status: degraded` and `success: false` expose the content loss. `compiled_with_errors` is also unsuccessful even if a PDF exists. Read the repair report in `response_body`; do not silently accept either as a complete deliverable. A model timeout or unreachable endpoint prevents the subsequent destructive bisect. After `status: compiled`, `success: true` and zero errors, deliver the path and stop unless an unmet requirement warrants another edit. State-changing, so it appears in the Exec Report, and because it writes files and runs a compiler it also asks permission when Ask Execs is on. The visual-canvas counterpart of the `chat_agent_latexer` Multi-Turn tool. **30 opt-in styles across six families**: editorial, cute/nursery, cyberpunk, cosmic, electronics and extraterrestrial Tlamatini. `template` selects the document structure; `style` selects its visual identity. Controls: `subtitle`, `style_mode` (screen/print), `style_decoration` (none/restrained/rich), `style_cover` and six-digit `predominant_color`. Styles apply to generated scaffolds and bare fragments; requesting a style for a complete source/project or using an unknown style refuses. Empty style preserves legacy output. `list_styles` returns `listed`, `success: true`, `style_count: 30`, `distribution: not_probed` and a JSON catalog, not a PDF. Metadata and body remain LaTeX; escape literal special characters. The `input_text_b64`, `content_b64`, `find_text_b64` and `replace_text_b64` fields preserve complex source and take precedence over their literal counterparts when decoding succeeds. Beamer scaffolds take frame-body content; complete frame sequences belong in a complete source. Style metadata and successful compilation do not certify visual layout: inspect warnings and any requested layout evidence; LaTeXer has no normal `layout_clean` result. See the [full style guide](Tlamatini/agent/agents/latexer/STYLES.md). | | **Editor** | Makes a SURGICAL in-place edit to a single existing text file by replacing an EXACT string (`old_string`) with another (`new_string`) — the find-and-replace equivalent that changes a file WITHOUT rewriting it (prefer it over File-Creator when only part of an existing file should change). By default `old_string` must be UNIQUE in the file; it refuses on >1 match unless `replace_all` is true. For code with backslashes or quotes, pass `old_string_b64`/`new_string_b64` (base64) for a byte-exact channel. The edit preserves the file's exact line endings. Emits an `INI_SECTION_EDITOR` block (`file_path`, `status` edited/not_found/not_unique/noop/error, `occurrences`, `replacements`) and ALWAYS triggers `target_agents` so a downstream Forker can branch on the outcome. State-changing, so it appears in the Exec Report. The visual-canvas counterpart of the `chat_agent_editor` Multi-Turn tool. | | **Camcorder** | Captures from a SYSTEM CAMERA (webcam) via OpenCV — distinct from Shoter, which captures the SCREEN. Takes a single PHOTO (the default) or records a VIDEO segment of `video_duration_seconds` (no audio), saving the file with a timestamped, collision-proof name. By default the file lands in the user's Pictures folder under `TlamatiniCamcorder`; set `output_dir` to override. Pick a non-default camera with `camera_index` (0 = default). Resolution is optional — leave `resolution_width`/`resolution_height` at 0 to use the camera's native resolution (recommended; a webcam only supports a discrete set of modes), or request a specific one. Emits an `INI_SECTION_CAMCORDER` block (`output_path`, `output_dir`, `filename`, `media_type`, `camera_index`, `duration_seconds`, `resolution`, `fps`) so a downstream Parametrizer/Image-Interpreter can read the exact saved path, and always triggers `target_agents`. Read-only/observational like Shoter, but it STILL appears in the Exec Report (2026-06-07: EVERY Multi-Turn agent does). The visual-canvas counterpart of the `chat_agent_camcorder` Multi-Turn tool. | | **Recorder** | Records AUDIO from a system input device (MICROPHONE) via `sounddevice` and saves a WAV (written with the stdlib `wave` module) — the audio sibling of Camcorder (camera) and Shoter (screen). By default it records from the SYSTEM DEFAULT mic for `record_seconds` seconds; pick a specific mic on a multi-microphone machine with `device_index` (the agent logs the numbered input-device list at startup) or by name with `device_name`. Sampling rate is optional — leave `sample_rate` at 0 to use the device's native default rate (recommended; the device always supports it), or force `44100`/`48000`/`16000`. `channels` defaults to mono (1) and is clamped to the device's max. `input_gain_percent` applies a software/digital gain (100 = unity default, 200 = louder, 50 = quieter); it is post-capture scaling, not the hardware mic level, so amplifying may clip — the clipped-sample count is reported. By default the file lands in the user's Music folder under `TlamatiniRecords` with a timestamped, collision-proof name; set `output_dir` to override. Emits an `INI_SECTION_RECORDER` block (`output_path`, `output_dir`, `filename`, `device_index`, `device_name`, `sample_rate`, `channels`, `duration_seconds`, `gain_percent`, `clipped_samples`, `format`) so a downstream Parametrizer can read the exact saved path, and always triggers `target_agents`. Read-only/observational like Shoter/Camcorder, but it STILL appears in the Exec Report (2026-06-07: EVERY Multi-Turn agent does). The visual-canvas counterpart of the `chat_agent_recorder` Multi-Turn tool. | | **Whisperer** | **Direct chat microphone:** Mic beside Send starts host capture without an LLM decision and stops on the configured silence gate. Config → Mic (last entry) selects automatic submission with the current draft/modes or an editable transcript for manual Send, and configures device, gain, gate and recognition preferences per browser. Each recording snapshots its settings. It has no extra console, workflow artifact output or wrapped-tool Exec Report row. **Standalone/workflow surface:** SPEECH-TO-TEXT (STT / voice recognition): turns SPOKEN AUDIO into a STRING of text — the speech-to-text sibling of Talker (text-to-speech). It is 100% SELF-SUFFICIENT for the microphone: it OPENS, CONFIGURES (channels, sample rate, software gain) and RECORDS the mic ITSELF (it does NOT depend on the Recorder agent), or transcribes a given audio FILE when `audio_file` is set (`input_source` mic/file/auto). By default (`input_source: mic`) it LISTENS to the SYSTEM DEFAULT mic rather than recording a fixed block: a **SOUND GATE** keeps the recording alive while you are still talking and stops it on its own after `silence_timeout_seconds` (default **3.5**) of continuous silence. `record_seconds` is the SWITCH — **0 (the default) = gated**, any number you name = record exactly that long with the gate off (the same idiom as `sample_rate: 0` = the native rate); `silence_gate` (auto/on/off) forces the choice, `max_record_seconds` (default 300) is the hard ceiling for a gate that never fires (a radio left playing is never silent), and `silence_threshold_db` (0 = measure the room continuously, 9 dB above it, never above −50 dBFS) retunes it for a noisy room. The console REC bar grows a **live silence countdown** beside the VU meter — it fills as the room stays quiet, empties the instant you speak, and turns amber then red before it fires — and the stopped line says WHY it stopped. Pick another mic with `device_index` (the agent logs the numbered input-device list at startup) or `device_name`. Transcription uses **faster-whisper LOCALLY by default** (`engine: faster-whisper`): it AUTO-DETECTS an NVIDIA GPU (CUDA) and **ALWAYS falls back to CPU** on a machine without one (so it works everywhere), with `model` ∈ tiny/base/small/medium/large-v3/large-v3-turbo (default `base`) and `device` auto/cuda/cpu. For cloud STT set `engine` to `cloud-groq` or `cloud-openai` (key from config or `GROQ_API_KEY`/`OPENAI_API_KEY`). `language` "" auto-detects; `task: translate` outputs English. **Ollama CANNOT transcribe** (it has no audio input), so the recognition is always done by the ASR engine; setting `ollama_cleanup: true` only post-processes the FINISHED transcript's punctuation/casing with an Ollama LLM. Emits an `INI_SECTION_WHISPERER` block (`transcript_path`, `audio_path`, `input_source`, `engine`, `model`, `device`, `language`, `duration_seconds` — the length ACTUALLY captured, not the length requested —, `segments`, `word_count`, `status`, `capture_mode` gated/fixed/file, `stop_reason` silence/duration/max_duration/fixed_fallback, `silence_timeout_seconds`, `speech_seconds`, plus the transcript text as the body) so a downstream Parametrizer/Forker can read the recognized text and branch on `{status}` (transcribed/empty/engine_unavailable/error); always triggers `target_agents` (success or failure). Read-only/observational (audio in → text out), but it STILL appears in the Exec Report (2026-06-07: EVERY Multi-Turn agent does). **NOTE**: local transcription needs `faster-whisper` (`pip install faster-whisper`); if it is absent and no cloud key is set, Whisperer reports `status: engine_unavailable` rather than crashing. **VOICE COMMANDS (2026-09-12)** — Whisperer is also the front end of a *voice command*, the chat catalog's FIRST section: the transcript it produces becomes the PROMPT Tlamatini then executes, so the microphone replaces the keyboard (cards #121 *YOUR FIRST VOICE COMMAND* and #122 *SPEAK YOUR PROMPT*). On the canvas the same shape is `Whisperer → Parametrizer → `, copying `{response_body}` into that agent's instruction field — with a Forker on `{status}` first, because a blank (`empty`) or missing (`engine_unavailable`) transcript must never be fed onward as if it were something somebody said. The visual-canvas counterpart of the `chat_agent_whisperer` Multi-Turn tool. | | **AudioPlayer** | PLAYS an audio file through a system audio OUTPUT device (speakers / audio out) via `soundfile` + `sounddevice` — the playback counterpart of the media family (Shoter = screen, Camcorder = camera, Recorder = microphone-IN, AudioPlayer = speakers-OUT). Set `audio_file` to the path of the file to play (WAV/FLAC/OGG/AIFF, and MP3 with a recent libsndfile); the full absolute path of the played file is logged and emitted. By default it plays to the SYSTEM DEFAULT output device; pick another with `device_index` (the agent logs the numbered output-device list at startup) or by name with `device_name`. `volume_percent` is a SOFTWARE gain (100 = unity default, 200 = louder, 50 = quieter — NOT the OS volume slider; amplifying may clip and the clipped-sample count is reported). `time_played` sets how many SECONDS to play: 0 (default) plays the WHOLE file once; a positive value plays EXACTLY that long — a longer file is TRUNCATED, a shorter file is LOOPED (repeated to fill the time with a final partial segment), done with a streaming callback so a huge duration over a tiny file never allocates a giant buffer. Sampling rate is optional — leave `sample_rate` at 0 to play at the file's own native rate (recommended; correct pitch), or force a value (which alters pitch/tempo, as the audio is not resampled). It does NOT change the Windows OS default audio device. Emits an `INI_SECTION_AUDIOPLAYER` block (`input_path`, `input_dir`, `filename`, `device_index`, `device_name`, `file_sample_rate`, `play_sample_rate`, `channels`, `volume_percent`, `clipped_samples`, `file_duration_seconds`, `time_played_requested`, `played_seconds`, `play_mode`, `loops`, `partial_segment`, `format`, `status`) so a downstream Parametrizer/Forker can read the exact path, the time played, and branch on `{status}`; always triggers `target_agents` (success or failure). Observational/output (mutates no persistent state) like Shoter/Recorder/Camcorder, but it STILL appears in the Exec Report (2026-06-07: EVERY Multi-Turn agent does). The visual-canvas counterpart of the `chat_agent_audioplayer` Multi-Turn tool. | | **VideoPlayer** | PLAYS a video file (WITH audio) on a chosen DISPLAY (screen) — the on-screen sibling of AudioPlayer (speakers). Decodes any ffmpeg container (.mp4/.mov/.mkv/.avi/.webm) via `ffpyplayer` (whose pip wheel bundles ffmpeg+SDL — no external ffmpeg, no runtime download) and draws the window with the already-bundled OpenCV; if ffpyplayer is unavailable it falls back to SILENT OpenCV-only video (volume becomes a no-op, logged). Set `video_file` to the path of the file to play; the full absolute path of the played file is logged and emitted. `display_index` picks the monitor (-1 = primary, the default; the agent logs the numbered display list at startup). `volume_percent` is the audio volume (100 = full default, 50 = half, 0 = muted; over 100 capped at 100). `time_played` sets how many SECONDS to play: 0 (default) plays the WHOLE video once; a positive value plays EXACTLY that long — a longer video is TRUNCATED, a shorter one is LOOPED (repeated to fill the time with a final partial segment). `window_width`/`window_height` set the window size in pixels (0 = the video's native size); `fullscreen: true` fills the chosen display (ignoring the window size); `keep_aspect: true` (default) letterboxes instead of stretching. **Additional-params analysis**: it OMITS playback-speed/fps (native timing is used), decode-resolution/codec (intrinsic to the file; the window size controls only display scaling), and audio-track/subtitle selection (advanced) — all rarely needed. Emits an `INI_SECTION_VIDEOPLAYER` block (`input_path`, `input_dir`, `filename`, `display_index`, `display_geometry`, `video_width`, `video_height`, `window_width`, `window_height`, `fullscreen`, `volume_percent`, `backend`, `has_audio`, `file_duration_seconds`, `time_played_requested`, `played_seconds`, `play_mode`, `loops`, `partial_segment`, `format`, `status`) so a downstream Parametrizer/Forker can read the exact path, the time played, and branch on `{status}`; always triggers `target_agents` (success or failure). Observational/output (mutates no persistent state) like Shoter/AudioPlayer, but it STILL appears in the Exec Report (2026-06-07: EVERY Multi-Turn agent does). The visual-canvas counterpart of the `chat_agent_videoplayer` Multi-Turn tool. | | **Talker** | TEXT-TO-SPEECH (TTS): SPEAKS text aloud through a system audio OUTPUT device (speakers) by driving an OLLAMA connection that runs a neural TTS model (default `Orpheus-3b-FT`) — the voice-synthesis sibling of the media family (AudioPlayer plays an existing FILE; Talker GENERATES speech from text). Set `input_text` to the words to pronounce. **FEMALE VOICE ONLY (Tlamatini is female): a male voice is FORBIDDEN BY DESIGN, with no override.** `voice` picks one of the permitted FEMALE Orpheus voices: tara [default], leah, jess, mia, zoe (`gender` accepts only `female`, used when `voice` is empty). Requesting a male voice (leo/dan/zac) or `gender: male` makes Talker close its execution entirely and report "male voice is forbidden by design — NOW CLOSING.. BYE" — it never substitutes and never sounds male. `emotion` weaves a paralinguistic tag into the speech (laugh/chuckle/sigh/cough/sniffle/groan/yawn/gasp) — or inline `` etc. directly in `input_text`. `language` passes a hint to the model (the base model is English-only; a multilingual fine-tune speaks others). `model`/`ollama_url`/`ollama_token` configure the Ollama connection; generation knobs are `temperature`, `top_p`, `top_k`, `min_p`, `repetition_penalty` (keep ≥ 1.1), `max_tokens`, `seed`. The model streams audio TOKENS that are decoded to a 24 kHz waveform by the SNAC neural codec; the WAV is saved to `output_dir` (default the user's Music folder under `TlamatiniTalker`) and played on the speakers (`device_index`/`device_name`/`volume_percent`/`sample_rate`; `play_audio: false` saves without playing). Emits an `INI_SECTION_TALKER` block (`output_path`, `output_dir`, `filename`, `model`, `language`, `voice`, `gender`, `emotion`, `sample_rate`, `audio_seconds`, `char_count`, `played`, `status`) so a downstream Parametrizer/Forker can read the spoken-WAV path and branch on `{status}`; always triggers `target_agents` (success or failure). Observational/output (mutates no persistent state), but it STILL appears in the Exec Report (2026-06-07: EVERY Multi-Turn agent does). **NOTE**: fetching the tokens needs only the stdlib, but rendering audible audio needs `snac` + `torch` (a neural vocoder) installed (`pip install snac torch`); without them Talker saves the audio tokens and reports `status: tokens_only`. The visual-canvas counterpart of the `chat_agent_talker` Multi-Turn tool. | | **Mouser** | Mouse movement, clicks, drags, scrolling, window anchors, and reference-image matching. Explicit `coordinate_space` supports physical screen pixels, desktop offsets, window/client positions, normalized positions, and screenshot-to-screen mapping. Handles negative monitor origins, rejects monitor gaps, checks window focus/point ownership for targeted actions, and refuses ambiguous window/image matches. `movement_type: inspect` returns cursor and monitor geometry without input. Reports `action_status` and observed coordinates; input delivery is not application-outcome verification. Reserved for requested desktop UI work; use File-Creator, Executer, and Pythonxer for file/code tasks. | | **Torrenter** | Controls persistent Tlachihuani Jobs downloads for the signed-in account. Review torrent metadata, select files, submit, pause, stop, resume, remove records and read verified manifests. File erasure requires approval in XT. | | **Terminater** | Raises REAL `cmd.exe` / PowerShell terminals — visible terminals inside Tlamatini's Terminals area (Views ▸ Terminals, or Ctrl+`) — where the USER watches the work, can interrupt it, answer a question the command asks, or finish a line Tlamatini only started. The visible sibling of Executer: Executer runs a command and returns text; Terminater TYPES every key like a person (default 50 words per minute, never pasted, never instant) and then reads the output back in full. Config → Live Editor & Terminater controls saved pace, shell, manual Enter, waits, narration and appearance; new flows can use account defaults while older explicit flows remain compatible. Runs ONE `action` per run (`run` is the default: open-or-reuse a terminal, type, wait, read) — `open`, `type`, `send_key`, `wait`, `read`, `commands`, `abort` (Ctrl+C, then the command's processes), `kill`, `force_kill`, `kill_all`, `list`, `focus`, `rename`, `layout` (`tabs`, `tile`, `tile-h`, `tile-v`, `grid`), `watch_user`, `warn_user` and `handover` — and terminals persist between runs, so a flow can open one in one step and close it in another. `<>` inside the text hands the keyboard to the user at that point (`ping <> -n 2`). A command that hangs (no output for `hang_seconds`) is detected and can be aborted; a deterministic advisor warns about dangerous or mistyped commands. Emits an `INI_SECTION_TERMINATER` block (`status`, `exit_code`, `typed`, `user_part`, `terminal_id`, …) and ALWAYS starts its `target_agents`, so a downstream Forker can branch on `{status}` (`completed`, `command_failed`, `hung`, `operator_required`, `aborted`). Windows 10 1809+ (ConPTY). | | **Windower** | The window manager of the desktop-UI trio (Windower = the window itself, Mouser = clicks inside it, Keyboarder = typing into it). Locates an application window by title and runs ONE lifecycle operation on it — `focus`/raise, `minimize`, `maximize`, `restore`, `move`, `resize`, `move_resize`, `close`, `topmost`/`untopmost`, or `arrange` (snap/tile to a screen region) — or `list`s every open window with its position, size and state. Matching is by `substring` (default), `exact`, or `regex`, with `match_index` to pick among same-titled windows. Implemented self-contained with the Win32 API (pywin32), including the reliable cross-process focus-transfer (AttachThreadInput) ported from Microsoft's Windows-MCP. Emits an `INI_SECTION_WINDOWER` block (`action`, `window_title`, `matched`, `match_count`, `state`, `left`, `top`, `width`, `height`) so a downstream Forker can branch on `{matched}`/`{state}` and Parametrizer can pipe geometry onward; always triggers `target_agents`. **Use Windower — not Mouser — whenever the goal is the window as a whole (bring to front, tile, resize, close by title); Mouser only clicks controls inside a window.** The visual-canvas counterpart of the `chat_agent_windower` Multi-Turn tool. | | **Keyboarder** | Checked Windows keyboard input, bound to one HWND/PID and stopped on foreground focus loss. Supports literal Unicode text (`input_mode: text`) including accents and emoji, plus the existing quoted-text/key/chord sequence syntax. Uses SendInput, checks inserted-event counts, releases owned modifiers on failure, and keeps the corner emergency stop enabled. Reports `action_status`, input counters, and target identity. Input delivery does not verify the focused field or its resulting content. Reserved for requested desktop UI work; use file/execution agents for authoring or running code. | ### Notification Agents These are *terminal* agents — they react to upstream events but do NOT start anything else. Their job is to tell the outside world that something happened. | Agent | Description | |-------|-------------| | **Notifier** | The browser-notification agent. Watches its `source_agents` for any of a comma-separated list of `search_strings` and, on a match, drops a `notification.json` file that the Tlamatini chat UI polls and renders as an in-browser DOM popup (with optional sound). Per-source file offsets and reanim files mean it never re-processes old log content even across restarts. | | **Emailer** | Sends an SMTP email when triggered. Configurable sender, password, list of recipients, subject, and body. Common pattern: wire a Raiser to detect the success or failure of an upstream pipeline and have it trigger Emailer to notify a team mailing list. | | **RecMailer** | An IMAP email receiver with LLM analysis. Polls a configured inbox, downloads new messages, and asks an Ollama model whether the body matches one of your `keywords_or_phrases`. Logs every match with the configured `outcome_word`. Use it to make a flow react to a real email arriving, e.g. an alert from an external SaaS. | | **Whatsapper** | The single WhatsApp send/receive agent with two explicit outbound identities. Three `mode`s remain available: `send` (post a `message`/`template` then start `target_agents` and die), `receive` (listen on the official webhook for `rx_max_seconds`, then start `target_agents` and die), and auto (infer from config). Address the recipient by a `contact_name` resolved from the Contacts book (`contacts.json`, next to `config.json`) or by a literal `whatsapp.to` number. Pick WHICH NUMBER sends with `provider`: `cloud` (default) uses Meta's **official WhatsApp Cloud API** from the BUSINESS number, with System User, template, and 24-hour-window rules; `web` sends from YOUR OWN personal number by automating WhatsApp Web after a one-time QR login, with no templates or System User. Plain English works, so "send it as me" / "from my own WhatsApp" → `provider=web` and "as the business" / "official" → `provider=cloud`. The `web` route is UNOFFICIAL and can get a number Meta-banned; the `web:` config block (`headless` / `login_wait_seconds` / `settle_seconds` / `profile_dir`) tunes it and the QR login is remembered per install. It STARTS `target_agents` and is a Parametrizer source emitting `INI_SECTION_WHATSAPPER` (fields `mode`, `direction`, `recipient`, `status`, `message_id`; body = `response_body`). Handy as a "page my phone when the build breaks" channel or a webhook-driven inbound trigger. | | **Telegrammer** | The single Telegram send/receive agent using official Telegram surfaces only. Bot mode uses the official Telegram **Bot API** (`telegram.bot_token` from @BotFather); optional user mode uses the official Telegram API session (`telegram.api_id`, `telegram.api_hash`, `telegram.session_name`/`session_string`) so private `@username` sends can stay human-readable in configs. Three `mode`s: `send` (post a `message` to a `telegram.chat_id`/`@username` or `contact_name`, then start `target_agents` and die), `receive` (listen for `rx_max_seconds`, optionally filtered by `rx_from_chat_id` / `rx_match`, then start `target_agents` and die), and auto (infer from config). Address the recipient by a `contact_name` resolved from `contacts.json`; that contact may keep `telegram: "@username"`. Telegrammer uses a local username cache plus official Bot API `getChat`/`getUpdates` lookup, and falls back to the official user-session API when configured. Pick WHICH IDENTITY sends with `provider`: `bot` sends AS the bot (Bot API), `user` sends AS your own logged-in account (user session, for private `@username` sends); plain English works, so "send it as me" → `provider=user` and "as the bot" → `provider=bot`, while `auto` (default) uses your account for private `@usernames`/`+phone` and the bot for numeric ids/channels. It STARTS `target_agents` and emits `INI_SECTION_TELEGRAMMER` (fields `mode`, `direction`, `chat_id`, `status`, `message_id`; body = `response_body`). | | **Monitor-Log** | A pure log-file watcher with LLM event detection. Polls a configured `logfile_path`, feeds new lines to an Ollama model, and logs `outcome_word` (default `TARGET_FOUND`) when a match is detected. Designed to be the upstream `source_agents` of a Raiser — together they form the canonical "react to a log line" mini-flow. | | **Monitor Netstat** | The network-port version of Monitor-Log. Polls the system's open TCP/UDP connections, feeds them to the LLM, and emits `TARGET_FOUND` when the configured network condition matches. Use it for "alert me if port X opens" or "fire when no connection to host Y exists for N seconds". | | **FlowHypervisor** | Watches a running flow using process state, logs and current agent contracts. It distinguishes execution branches from Ender kill lists and log/data dependencies, includes configured desktop timing, and retains the latest mouse/keyboard receipts between log polls. It alerts on problems; input delivery is not treated as proof that an application was edited, saved or closed. | ### Utility Agents Glue and infrastructure agents — they do not directly produce output but make the rest of the canvas easier to wire. | Agent | Description | |-------|-------------| | **Parametrizer** | Carries structured results from one agent into another agent’s configuration, one segment at a time. Its parser registry follows all declared output producers (50 currently, including Keyboarder). It preserves empty fields, checks numeric and Boolean conversions, and requires every configured mapping to succeed before writing or starting the target. It backs up and restores the target config and blocks automatic replay of interrupted mouse/keyboard input until application state is checked. | | **FlowBacker** | A passive backup utility. When triggered (typically by Ender), it copies the entire deployed session pool directory to a configured `target_directory`, overwriting any previous backup of the same session, then launches its `target_agents` (Cleaners). The "save before you wipe" step in any flow that ends with cleanup. | | **FlowCreator** | Designs a workflow from your objective. It first selects from all 87 installed agent types, then uses their detailed instructions and current configuration/connection contracts to produce a .flw file. It checks references, branches, fields and Parametrizer mappings before publishing, with bounded repair for invalid plans. The generated flow remains reviewable before you run it; catalog coverage does not guarantee every external application or service is ready. | ### Cryptography Agents Post-quantum cryptography primitives, deterministic and short-running. | Agent | Description | |-------|-------------| | **Kyber-KeyGen** | Generates a CRYSTALS-Kyber post-quantum public/private key pair in base64. Three variants are supported: `kyber-512`, `kyber-768` (default), and `kyber-1024`. Output is logged in a structured block so a downstream Parametrizer can route the keys directly into Kyber-Cipher and Kyber-DeCipher. | | **Kyber-Cipher** | Encrypts a plaintext buffer with a CRYSTALS-Kyber public key. Internally uses Kyber **encapsulation** to derive a shared secret and AES-256-CTR to encrypt the buffer; the agent logs the encapsulation, IV, and cipher text in base64, all wired so they can be piped into Kyber-DeCipher by Parametrizer. | | **Kyber-DeCipher** | The inverse of Kyber-Cipher. Decrypts a base64 cipher text using the matching CRYSTALS-Kyber **private key** plus the encapsulation and IV that Kyber-Cipher emitted. Emits the recovered plaintext into its log, ready for File-Creator or another consumer. | ### Multi-Channel Bridges Long-running listeners that bridge external messaging platforms into the full Multi-Turn Tlamatini chat (with tools, context, ACPX, and Exec Report). | Agent | Description | |-------|-------------| | **TeleTlamatini** | A long-running Telegram bot that bridges authorized Telegram users into the **full Multi-Turn + Exec Report Tlamatini chat**. Each user message is treated as a chat turn; the answer (including tool calls, ACPX runs, and Exec Report tables) is rendered back into Telegram. Authorization is by Telegram user ID. The "use Tlamatini from your phone, while away from the keyboard" agent. | ### External Coding-Agent Driver The visual canvas counterpart of the 12 LLM-facing `acp_*` ACPX tools. | Agent | Description | |-------|-------------| | **ACPXer** | Drives one external coding-agent CLI session per run — Claude Code, Codex, Cursor, Gemini, Qwen, the Tlamatini self-host, Kiro, Kimi, iFlow, Kilocode, OpenCode, Pi, Droid, or Copilot. The agent spawns the chosen `agent_id`, sends its `task`, waits for the child to settle (using a transport-aware drain rule), captures the assistant's last reply, and then kills the child cleanly. Output is emitted as a Parametrizer-compatible `INI_SECTION_ACPXER` block (`agent_id`, `session_id`, `transport`, `settle`, `transcript_path`, `response_body`), so chains of ACPXer nodes connected through Parametrizers form a fully visual multi-CLI relay — three different LLMs arguing back and forth in an unattended pipeline. | --- ## Notes on Maintenance - **Adding a new agent**: append a new row to the relevant table above using the same Markdown format. The parser only requires `^\|\s*\*\*\*\*\s*\|\s*\s*\|`. Section headings (`### ...`) are ignored by the parser; they exist purely for human readers. - **Renaming an agent**: change the `**Name**` cell — but remember the lookup is normalized to lowercase alphanumeric, so `**Kyber-KeyGen**`, `**KyberKeyGen**`, and `**kyber keygen**` all hit the same slot. As long as your normalization matches the DB display name, the tooltip stays connected. - **Frozen builds**: `build.py` copies this file into `dist/manage/agents_descriptions.md` so it ends up in the install directory next to `Tlamatini.exe`. The view loader probes `agents_descriptions.md` first, then falls back to `README.md` (so older deployments that haven't updated yet still work). Model selection: Config → Models manages 38 model/engine/voice settings across Core, Vision, Speech, Workflows, Documents and Monitoring & messaging for all 21 model-backed agents. Preserve quoted `"@config"` and omitted registered fields as inheritance; never replace them with guessed tags. Literal canvas/standalone values are overrides. Wrapped chat starts from globals, then explicit tool arguments; standalone MCP resolves inherited template values before invocation overrides. Do not volunteer model arguments unless the user asks. Save applies on the next configuration load; reconnect chat and restart already running agents as needed. Talker requires an Orpheus-compatible model and supported voice. Whisperer local/cloud engine and cleanup model are separate; cleanup still needs `ollama_cleanup: true`. Video audio uses its independent local `transcription.model`. Empty Whisperer cloud model selects the provider default; empty LaTeXer repair model disables repair. Credentials, URLs, audio devices and external ACPX/MCP provider settings remain separate. Image/video model failures accumulate in the shared themed fatal-error dialog. Preserve Tlamatini's existing retry and recovery tactics and the configured model identities. Never substitute a model or accept missing-observer/raw-concatenation output as success; HTTP 410 may indicate retirement. Robotics cannot report PASS from missing evidence. See `docs/model_configuration.md` for all defaults, paths and source/frozen checks. ## Image/video error reporting and recovery (2026-09-26) Image/video model failures accumulate in one shared, themed, non-modal fatal-error dialog with an audible notification. Tlamatini keeps running: preserve its retry/tactic ladder, cancellation controls and configured flow recovery routes. Keep the configured model identities; never report a surviving observer or raw concatenation as successful analysis. Dismiss hides the dialog while retaining its history; new failures reopen it. See [the shared behavior and verification contract](docs/visual-analysis-errors.md).