Chat

Chat in LatchAI is not a sidebar bolted onto an editor. It runs inside the engine, on the same provider, the same tool registry, the same multi-root filesystem, and the same event bus as workflow runs — which is why a chat turn can edit a file, run a test, and show up in the same review surfaces a scheduled run does.

Open it with ⌘⇧L, or from the ▤ chat button in the status bar.

Tool calls appear inline as chips; the full entries land in the events panel.

Who answers

One dropdown at the bottom of the panel decides that, and it has two halves:

• Models — everything in the Models page Library: models downloaded to this Mac (listed as local:<name>, with ● marking the one currently loaded in memory) and connected providers. Talking to a model directly gets LatchAI’s built-in assistant persona.
• Agents — your agent definitions, grouped by their group frontmatter. Picking one swaps in its system prompt, its tool allowlist and its model for this conversation.

A local model for routine questions and a large hosted one for the hard problem is a per-conversation decision, not a global setting.

Note

The offline mock provider is hidden from the picker unless it is the only provider configured, or it is the resolved default — in which case it stays visible on purpose, so a misconfigured setup shows you “mock” rather than quietly masquerading as a real model. And whenever that demo model is what’s actually answering, the panel says so: a banner above the composer marks replies as canned examples, with a link to Models (or, while a local model is still downloading, the download’s live progress).

The default persona

Talking to a model directly, LatchAI’s assistant is deliberately conversation-first: it is told to answer in the chat rather than writing a file to explain itself, to prefer read-only tools while exploring, and to reserve write_file, edit_file and run_shell for changes you actually asked for — ending with a one-line list of the paths it touched.

It also gets a compact index of your workflows — one line each, with the node shape and any cron schedule — so “what runs overnight?” is answerable without reading a single file.

Context

Two things reach the model as context, and it’s worth knowing which is which:

• The active tab, by name. A file tab contributes user is viewing file "<path>"; a workflow tab contributes its id and name. This is a pointer, not the contents — the assistant reads the file with a tool if it needs to.
• @ mentions, by contents. Typing @ in the composer autocompletes against the file tree; up to five mentioned files are fetched and inlined, capped at 12,000 characters in total.

Both are folded into one [context: …] prefix on the message, which is stripped back out of the transcript when a session is reloaded, so re-opening a chat doesn’t show you the plumbing.

Pasted images are attached as thumbnails and sent as vision blocks — the OpenAI-compatible provider expands them to image_url parts, the Anthropic provider to base64 image blocks.

Tools

Chat has the same tool surface agents do: file reads and edits, shell, semantic search, diagnostics, web fetch, skills, and every connected MCP server. Calls stream as they resolve, and the set_plan tool drives a live plan strip above the conversation so a long multi-step turn is legible while it happens.

While a turn is working, the last six tool calls, results and shell commands show as chips under a ⟳ working… line; the full entries land in the events panel (⌘J). A chat turn’s events are excluded from the Run Monitor — the panel you are already looking at is the better view of them.

Reviewing what it changed

Every chat turn is checkpointed. The ± Review changes affordance opens the diff for that turn in the review overlay, with a revert — the same machinery workflow runs use, so “what did the assistant actually do” has one answer everywhere in the product.

A chat turn’s file changes, reviewable and revertible.

The button appears once the turn finishes and carries the checkpoint’s short sha. It shows only when the turn actually changed something: no files touched, no checkpoint, no button.

Refining a dashboard in conversation

Open the chat while a dashboard tab is active and the turn is bound to that board. Two things follow. The assistant is given bounded context — the brief, every widget’s summary and displayed data, and an index of the run’s sources (labels and refs, never the payloads). And publish_dashboard resolves against that board, so “drop the token count and make the list full width” re-renders the live dashboard instead of describing a change to it.

dashboard_source fetches one archived payload on demand when a question needs the numbers behind a number rather than the summary.

Persistence

Sessions persist twice, deliberately:

• Canonical envelopes at <home>/runs/chats/<id>.json — the exact messages including tool turns. These survive restarts and are what a resumed session replays.
• Markdown mirrors in <home>/workspace/chats/ — YAML frontmatter (session, created, updated, tags: [latchai, ai-chat]) and timestamped turn headings. Point an Obsidian vault at that folder, or symlink it, and every conversation is indexed and linkable with no plugin.

The mirror is written on every turn, named <date>-<slugified-title>-<id-suffix>.md, where the title is the first line of your first message. It looks like this:

---
latchai: chat
session: chat-1748...
created: 2026-07-28T09:14:02.113Z
updated: 2026-07-28T09:21:40.882Z
tags:
  - latchai
  - ai-chat
---

# Why is the webhook returning 404?

## You — 09:14:02

Why is the webhook returning 404?

> ⚙ tools: read_file, search_code

## LatchAI — 09:14:31

Because `hook-echo` has no `webhook_trigger` node…

Tool calls are recorded as that one > ⚙ tools: line; the full arguments and results stay in the JSON envelope, which is what keeps a vault note readable.

The ≣ button in the panel lists saved sessions newest-first with their message counts, and reloads any of them. A reload restores the user and assistant prose; tool turns are not re-rendered as chips, but they are still in the envelope, so the model resumes with the complete history.

Limits worth knowing

• One turn at a time per session. Sending while a turn is working comes back as “still working on the previous message” rather than queueing.
• Turn budget. A chat turn stops after 80 tool-loop turns as a runaway backstop. An agent’s own maxTurns applies to workflow nodes and delegation, not to chat.
• Tool turns don’t stream. As everywhere in LatchAI, a turn that offers tools is requested non-streaming; you see progress through tool chips rather than tokens.
• The conversation itself is not run history. The chat.* events — messages, deltas, busy status — are excluded from <home>/runs/*.jsonl on purpose. The turn’s work is logged: its tool calls, file writes and checkpoint land in a chat-<session>-<timestamp>.jsonl log like any other run, which is how the brain can connect a conversation to the files it touched.