# The Console

> Asking free-form questions across every connected system, pinning a playbook, and choosing a model.

Source: https://triagic.com/docs/desktop/console

The Console is a ticket-free investigation. You ask something in plain English and
the agent works across every data source you have access to.

Use it when there is no ticket yet: a customer is on the phone, an alert fired, or
you want to check something before someone files anything.

## Asking well [#asking-well]

The agent is good at finding things and bad at reading your mind. Two habits pay off
immediately:

**Name the entity.** "Why is checkout failing?" makes the agent guess a scope.
"Why is checkout failing for merchant `cedar-sage` since about 14:00 UTC?" gives it a
merchant, a subsystem and a time window to filter on, and the answer arrives in fewer
iterations for less money.

**Say what you already ruled out.** "Payouts are stuck for Acme Coffee, the payout
row exists and the bank is verified" stops the agent re-checking what you checked.

## Developer and support mode [#developer-and-support-mode]

The composer has a **developer / support** toggle that sets who the answer is written
for. The investigation underneath is identical, same tools, same evidence. Only the
final answer changes register.

**Developer** is the default: full technical detail, with table names, error codes
and log excerpts attributed to the system they came from.

**Support** rewrites the answer in plain English for a support agent. It opens by
answering the question asked, explains what happened without naming internal systems
or quoting errors, and ends with the concrete next steps. When a customer is waiting,
that includes a short suggested reply that can be sent as-is.

The choice sticks on your machine and applies per question, so you can flip it
mid-thread: ask in support mode for the customer-facing answer, then switch to
developer mode to dig into the same thread's technical trail.

## Pinning a playbook to a thread [#pinning-a-playbook-to-a-thread]

A Console thread can be pinned to any playbook you have access to. Doing so applies
that playbook's triage instructions and its data-source allowlist to the whole
conversation.

This is worth doing for a focused question: a thread pinned to *Platform Reliability*
will not go rummaging through the payments database, so it answers faster. It is
worth *not* doing when you genuinely do not know where the problem is.

## Threads and memory [#threads-and-memory]

Every Console investigation gets its own thread, owned by you and private to you.
Threads replay the last 20 turns on every call, so multi-turn conversations build on
prior answers rather than starting cold. Tool traces stay in the UI and out of the
model's context, so you keep the audit trail without paying for it in tokens every
turn.

Resume a thread from [History](/docs/desktop/history-and-usage); the stored tool and
cost chips replay with it.

## Choosing a model [#choosing-a-model]

The composer has a model picker. What it offers is your organization's configured
deployments. See [AI providers](/docs/admin/ai-providers).

Resolution order, highest priority first:

1. The model picked for this thread.
2. The install's runtime default, set on the **Usage** page.
3. The configured fallback.

An override for a model that is not in the registry is ignored rather than failing.
Background triage and the playbook classifier always follow the runtime default
and never use a per-thread override.

## Scheduled reports [#scheduled-reports]

Reports a playbook runs on a cadence have their own page, so this list holds only the
threads you started. See [Reports](/docs/desktop/reports).