cairn ask
cairn ask turns intent into governed plans and answers questions about the
platform’s state. It is safe by construction, not by prompt: the agent’s
entire tool belt is the read-only API surface — there is no run, resume,
cancel, install, or admin tool for it to call, so it literally cannot mutate
anything. When you ask it to do something, it resolves the right workflow
and hands back a ready-to-run plan for a human to execute.
cairn ask # interactive REPLcairn ask plan training/finetune -i model=... # deterministic plan, no LLM; exit 0 iff runnablecairn ask run "fine-tune a model on my support tickets"ask plan assembles the plan for a known template deterministically.
ask run uses an LLM only to resolve intent → template, then runs the same
deterministic planner and prints the plan plus the exact cairn run command —
it does not execute. Flags: --profile, --model (default gpt-4o-mini),
--json.
The server agent — POST /ask
Section titled “The server agent — POST /ask”The server exposes a ReAct read agent over the same governed core:
POST /ask {"query": "...", "thread_id": "..."} (auth required)GET /ask/thread/{thread_id}- Read tools only — query runs, costs, audit, remote jobs, packs and contracts, grounded knowledge retrieval.
- Grounded answers — the system prompt is fail-closed: it answers from tool results, not world knowledge.
- Tenant-scoped server-side — account and workspace come from the authenticated request, never from the body; thread ids are namespaced per account, so a guessed id yields an empty transcript.
- Cost-bounded and audited — each turn runs under a hard budget cap
through cairn’s own governed model gateway, and every answer emits an
ask.answeredaudit event (query, tools used, recommended workflow). - Durable conversations — with
OBS_CHECKPOINTER=postgres, ask threads survive restarts.
When the answer is “run this workflow”, the response carries a structured
action that surfaces the run form — the human clicks, policy applies as
always.