NavFlow agents

A NavFlow agent is a prompt attached to a trigger. When the trigger fires, the agent is handed the correlated timeline for the affected entity, reads it (and can read a wider window or another entity), and writes its findings back into NavFlow — an event on that entity’s timeline.

It’s a real agent (it reasons with an LLM), configured inside NavFlow. That distinguishes it from a connected agent — an external agent you wire up over MCP or a webhook, which lives in your own infrastructure and can act on your systems. A NavFlow agent only reads NavFlow and writes a finding back; it never acts on the outside world. Both kinds are woken by the same trigger.

Because a finding is also stored as an event on the entity’s timeline, the next agent to read that entity (including your own connected agent) receives NavFlow’s prior conclusions as part of the evidence. NavFlow doesn’t replace your agent; it gives it a head start.

Create one

In the console, open a trigger and choose Add a NavFlow agent (or go to Agents → Create NavFlow agent). You supply the prompt which can be optionally seeded from a preset. Everything else (model, tools, budgets) is preset.

A NavFlow agent is enabled exactly when it is subscribed to its trigger, the same wiring a connected agent has. New agents start disabled; enable it to run on the next firing. It appears alongside connected agents under Agents, in the trigger’s woken-agents list, and in recent firings.

In the catalog

An agent is a catalog object, so it exports/imports with everything else and can be shipped in a seed catalog:


agents:
  - name: incident-first-look
    trigger: incident            # the trigger that wakes it
    enabled: true                # enabled ⟺ subscribed to the trigger
    prompt: |
      You are an SRE taking the first look when an alert fires on this service. You are handed the
      correlated timeline — the firing alert plus the signals behind it and the request logs.
      Produce a tight incident note: what is failing and since when, the most likely cause tied to
      specific evidence lines, and a suggested next action. Do not speculate beyond the evidence.

The bundled demo ships exactly this agent, so navflow up closes the loop with nothing to deploy.

Findings

An agent’s conclusion is written to the built-in findings source (auto-provisioned on the first finding), keyed to the entity the trigger fired on. Because it’s treated as an event, it lands on that entity’s timeline and is returned by read / query like everything else. Each finding carries the agent, the trigger, the firing, and a hash of the prompt that produced it.

The run itself (status, rounds, duration, errors) is recorded separately, under the agent’s page → Runs & findings — a run that concludes “inconclusive” or fails never pollutes a timeline.

The Anthropic key

A NavFlow agent runs on Anthropic’s API. Provide a key one of two ways:

ANTHROPIC_API_KEY in the daemon’s environment, or
the console → Security → Anthropic key.

The environment key wins if both are set. Without a key an agent can be created but not enabled; if it’s already enabled, each firing is logged as “no key” and no finding is written. The same key powers the in-app Ask assistant.

Tools and the boundary

A NavFlow agent has exactly two tools, both routed through NavFlow’s own read path:

read — one correlated timeline for an entity across all sources.
query — a timeline through a saved view.

That’s the boundary: a NavFlow agent reads and concludes; it does not act (no restarting, deploying, or ticketing). Anything that touches your systems belongs to a connected agent, wired over MCP or a trigger webhook — that agent can act, and it benefits from the findings a NavFlow agent already left on the timeline.

Notifications

An agent can post its finding to Slack (an incoming-webhook URL on the agent). Slack carries the full finding text so it stands alone even for a local instance with no public URL.

Guardrails

Cooldown — the agent runs at most once per the trigger’s cooldown per entity.
Daily cap — a per-agent daily run cap bounds cost (default 50; NAVFLOW_AGENT_DAILY_CAP).
No self-feeding — an agent can’t be woken by a trigger that watches the findings source it writes to; NavFlow rejects that wiring.

Triggers - the condition that wakes an agent.
Connecting agents (MCP) - external agents that read on demand and can act.
Demo - see a NavFlow agent diagnose an injected incident end to end.