From single-shot inference to agentic sensing loops

"You asked me once what the vibration meant. I answered once. Then the bearing kept spinning, and nobody asked again. That is not perception; that is a photograph."

A Looping AI Agent

The distinction is not cosmetic. A single-shot call has a fixed information budget: whatever you managed to stuff into the prompt is all the model will ever see before it commits to an answer. For a photograph or a sentence that can be enough. For a bearing that is beginning to spall, a patient whose rhythm is drifting, or a substation whose load is climbing, the decisive evidence often arrives after the first look, or lives in a second sensor the first prompt never mentioned. The loop exists to let the model go get that evidence.

The single-shot ceiling

What single-shot inference is: one forward pass, \(\hat{y} = f(x)\), where the input \(x\) is frozen at call time and the model has no way to request more. Why it hits a ceiling on sensor problems is threefold. First, the evidence is incomplete by construction: a fault signature may span three sensors, but you cannot pre-load every sensor into every prompt without drowning the model and the budget. Second, the world keeps moving: by the time the answer is generated the process has advanced, so a static answer describes a past that no longer holds. Third, the right next question depends on the current answer: if the vibration spectrum looks like an imbalance you check the mounting; if it looks like a bearing you check the lubrication temperature. A single shot cannot branch, because branching requires seeing your own intermediate conclusion. When single-shot is nonetheless correct: when the decision is genuinely local and terminal, such as tagging one already-captured window. Do not reach for an agent when a classifier will do; the loop earns its cost only when evidence-gathering is part of the task.

Anatomy of a sensing loop

Strip away the framework marketing and every agentic sensing loop has the same four organs, iterated until a stop condition fires. Perception turns raw or lightly processed signal into something the language model can reason over, typically a compact textual or tokenized summary of the latest window (the bridge of Chapter 21 is what makes this possible). Reasoning is the LLM step: given the perception and the accumulated memory, produce a thought and choose a next action. Action executes that choice against the outside world, most often by calling a tool (a spectral detector, a Kalman filter, a database query, a forecaster) whose result becomes new evidence. Memory is the running state that survives across turns: the hypothesis so far, which sensors have been checked, what the detectors returned. The loop closes when the model emits a terminal action (an explained alert, a "nominal" verdict) or a budget guard trips.

This interleaving of a reasoning trace with acting steps, each action's observation fed back before the next thought, is the pattern the literature calls ReAct (Yao et al., 2023). Its value for sensing is that the model's chain of reasoning is grounded at every step in a fresh measurement rather than spun from the prompt alone, which is precisely the antidote to the confident-nonsense failure mode that plagues a language model asked to reason about signals it cannot re-check.

The loop is a controller you already know

The agentic loop is not a new idea dropped in from natural language processing; it is the observe-decide-act cycle that runs through this entire book, with a language model sitting in the decision seat. Why the framing helps: it tells you what to import from control and estimation theory. A Kalman filter (Chapter 9) also loops forever, alternating a predict step with a measurement update, carrying a belief state \(x_t\) between iterations. Write the two side by side and the correspondence is exact:

Here \(z_t\) is a numeric measurement and \(o_t\) is an observation the agent chose to gather (a tool result, another channel), while \(g\) is a fixed algebraic update and the LLM is a learned, flexible one. The differences are as instructive as the parallel. A Kalman filter's measurement schedule is fixed in advance; the agent chooses what to measure next, which is its whole reason for existing. A filter's state is a calibrated probability distribution; the agent's memory is text, so it needs a bolted-on notion of uncertainty (the calibration machinery of Chapter 18, which Section 22.6 wires in). When this matters: any time you are tempted to think an agent replaces your estimator, remember it more often wraps one, deciding when to run the filter and how to read its output, not reimplementing it.

The listing below is the whole idea in fewer than thirty lines: a loop that perceives a window, lets the model choose one action, executes it, folds the result into memory, and repeats until the model concludes. It is deliberately skeletal so the four organs stay visible; the detector and summarizer are the pluggable tools of Section 22.4.

def sensing_loop(stream, llm, tools, max_turns=6):
    """Observe -> reason -> act -> remember, until the model concludes."""
    memory = []                                  # running state across turns
    window = next(stream)                         # latest slice of signal
    for turn in range(max_turns):
        obs = summarize_window(window)            # perception: signal -> text
        step = llm.decide(memory, obs)            # reasoning: pick ONE action
        memory.append((obs, step))                # remember what we saw + chose
        if step.action == "conclude":
            return step.verdict                   # terminal: explained alert / nominal
        result = tools[step.action](step.args)    # action: run a detector / fetch a channel
        memory.append(("tool_result", result))    # fold evidence back in
        window = next(stream)                      # world has moved; look again
    return {"verdict": "inconclusive", "reason": "turn budget exhausted"}

Listing 1 makes one thing concrete that prose blurs: the model does not act on the world directly. It emits a choice, and ordinary code executes it, which is exactly where guardrails will later intercept. That separation between deciding and acting is what keeps an agent auditable, and it is why the loop, not the model, is the unit of engineering.

from langgraph.prebuilt import create_react_agent
# tools are plain functions with type hints and docstrings
agent = create_react_agent(model="anthropic:claude-sonnet-4-5",
                           tools=[bearing_envelope, fetch_scada, forecast])
agent.invoke({"messages": [("user", summarize_window(window))]})

When to loop, and when not to

The loop is powerful and it is not free: every turn is a full model call plus a tool call, so latency and cost scale with the number of turns (the subject of Section 22.7). The design question is therefore sharp. Reach for a loop when the task requires sequential evidence-gathering: when the right next observation depends on the current finding, when evidence is spread across sources too numerous to pre-load, or when a hypothesis must be actively tested rather than read off. Stay single-shot when the decision is local and the input is complete: a fixed-window classifier on the edge (Chapter 60) has no business becoming an agent, and dressing it as one only adds latency, tokens, and new failure modes. A good rule: if you cannot name a second question the agent might ask, you do not need the loop. Root-cause investigation, where each answer narrows the next probe, is the canonical case that does need it, which is why Section 22.2 opens the chapter's real work there.

What's Next

In Section 22.2, we put the loop to work on the task it was built for: when a detector fires, an agent does not just repeat the alarm, it reasons backward through the evidence to explain why the anomaly happened, gathering the corroborating readings a root-cause story needs and assembling them into an account an operator can act on.