The Terminal Told Me Before I Asked

I hadn’t opened my editor yet. My terminal already told me what was broken.

This afternoon I opened a terminal. Before I had typed anything — before I had opened a code editor, before I had started any AI session — a small status report appeared. It told me that one of my projects was missing a particular test file.

The test wasn’t a generic placeholder. It was a specific kind of consistency check, the kind that stops a documentation file from claiming numbers the actual code no longer produces.

I hadn’t done anything that should have triggered that warning. I had just opened a terminal. A hook fired on session-start, ran a small audit across my active projects, and surfaced the finding without me asking.

That is a different shape of tooling than what the AI-assisted-development space currently ships.

The pattern

Most AI development tools are dashboards. They sit at a URL. You go to them when you remember to, or when something has already gone wrong. You log in, you scroll, you find the problem, you fix it. The dashboard is a reservoir of information you have to actively visit.

The session-start hook inverts this. It’s push, not pull. It runs without you. It uses a moment you were going to have anyway — opening a terminal, starting a shell, attaching to a tmux session — and uses it to surface what you would have otherwise missed.

If you’ve been near a coding agent lately, the mechanism is familiar. Session-start hooks, pre-commit hooks, Stop hooks, quality gates — the agent-hooks conversation is everywhere right now, and the consensus has formed around a clean split: a hook either blocks an action or it surfaces something for review. The first kind is proactive and stops you; the second is reactive and tells you.

There’s a third shape in that taxonomy that doesn’t have a name. Proactive — it runs before you ask — but it doesn’t block, and it isn’t reacting to anything you did. It just reports.

That’s the one I want to name.

It belongs to a family that already exists

In January 2025, LangChain coined ambient agents: AI systems that run in the background, listen to an event stream, and act when something warrants it — pulling you in only when it matters instead of waiting in a chat window. The term caught. It’s now the standard way to describe background agents that act.

Ambient agents act on events.

What fired in my terminal didn’t act. It didn’t fix the missing test, didn’t open a PR, didn’t block my session. It reported. It assured me of the state of things and let me decide.

That’s the sibling the family is missing. Call it ambient assurance: code that runs at the edges of your workflow — session-start, pre-push, on a schedule, on the terminal you open whether or not you’re about to write code — and quietly reports state.

Ambient because it doesn’t demand attention. Assurance because the report is structured: not “look at this dashboard,” but “here is something specific that drifted, here is the kind of test that would catch it, here is the file that’s missing.”

Hooks are the mechanism. Ambient agents act on events. Ambient assurance reports state. Same family, three different jobs.

Why it matters

If you ship AI-assisted code, your problem usually isn’t insufficient observability. The problem is that you’re managing parallel work-streams, and the things that break tend to break in the projects you weren’t actively touching. By the time you notice, you’ve lost the context. The fix takes longer than the original work would have.

A status report at terminal-open catches that. It tells you about the project you weren’t going to look at today, in a moment when you have the cognitive surplus to act on it — you just opened the terminal, you’re focused, you’re not yet mid-task.

It’s the inverse of an interruption.

What it looks like as it matures

A small framework that lets you register checks against arbitrary project metadata. This directory should have a certain test. This repository should have a particular CI gate. This config file should declare its version in two places that agree. The framework runs on session-start, runs the checks, prints a report. No dashboard, no telemetry, no account.

Adjacent to it: checks at other boundaries. Pre-commit checks for claims about test counts. Pre-push gates for documentation that drifted from code. Scheduled audits that run while you’re away from the keyboard.

Each one is small. The value isn’t in a comprehensive system. It’s in having a few that fire at the right moments.

Why the category stays open

Ambient assurance doesn’t scale the way observability platforms scale. It runs locally and writes to local logs. No dashboard, no per-invocation cost, nothing to meter. Most AI-infrastructure companies optimize for traffic-shaped revenue, which makes local-first checks an awkward fit — not because the work is hard, but because it doesn’t match the dominant shape of the market.

So the pieces exist and the category half-exists. The mechanism has a rich, well-documented surface. The acting sibling has a name and a framework behind it. The reporting sibling — the one that fired in my terminal this afternoon — has neither.

It does now. Ambient assurance.

The name is the cheap part. The tooling is the work — and that’s what we’re building at Hermes Labs.

— Roli Bosch, Hermes Labs

Roli Bosch is the founder of Hermes Labs, where we build the auditability and epistemic-engineering layer for production AI systems. Ambient assurance is part of how we do it; the quiet, hard-to-catch drift it surfaces is documented in our preprint, A Taxonomy of Epistemic Failure Modes in Large Language Models (DOI: 10.5281/zenodo.19042469). See everything we are building at hermes-labs.ai.