Three things: what changed in its world since the last pass, what it already did, and what its teammate loops left for it. That is the complete check for a well-run agent loop.

A briefing is not a check

The costliest habit in loop design is treating each waking as a fresh briefing, reassembling the full history, the standing facts, and the current state of everything so the agent can rediscover a world that mostly did not move. Oracle's engineering team estimates that agents consume roughly four times the tokens of a standard chat interaction, and up to fifteen times in multi-agent systems, driven substantially by context being rebuilt on each iteration, and that figure describes single tasks rather than schedules, so multiplying it across a loop's wakings turns the briefing habit into the dominant cost of running the thing at all. The buried signal costs more than the tokens do, because somewhere inside the restated world sits the one item that actually changed, and the agent has to find it by comparing everything against its own recollection of everything.

The three wake-up questions

Every well-designed loop opens its pass with the same short interrogation, and each question exists to kill a specific failure:

1. What changed in my world since my last pass? Which data arrived and which files moved
2. What did I already do? The loop reads its own last note before acting,
3. What did my teammate loops leave for me? Handoffs appear the moment a second loop exists, and the open-source fulcra-agent-teams skill makes the question concrete by giving every agent an inbox in a shared team space where the others drop tasks between passes.

Awareness is not the same as loading

The agent does not need to read the contents of everything it discovers, because the goal is knowing that something changed so it can fetch that thing if the work calls for it. Knowing a file moved costs almost nothing while reading the file costs real tokens, and collapsing those two operations into one is how loops  become expensive. The same logic governs what never enters the check at all, since standing facts about you and the loop's own purpose belong in its instructions where they are written once, while anything that did not change belongs nowhere, which sounds too obvious to state until you audit a real loop and find that unchanged context is most of what it reads.

The scan, concretely

The three questions come down to two operations. The first is a delta call covering the period since the last pass, which returns both the data types that had records processed and the files that changed, each with a path and a timestamp. The second is a listing of the loop's team inbox, which is a separate check rather than a field in the first response, with reading any particular message being a further step after that. Two checks and then targeted reads is the honest shape of a good wake-up, and Fulcra ships the routine as a skill your agent can install and follow on its own, with the sensible requirement that it ask your permission first.

‍

Frequently asked questions

How much context does a looping agent actually need? Less than intuition suggests, amounting to the delta since its last pass, its own last note, and any handoffs waiting for it, while standing knowledge lives in its instructions rather than in the per-waking payload.

Should my agent re-read its full history every run? No,  history belongs in files the loop consults on demand while the default read stays at the last note plus the delta.

Can one call tell an agent everything that changed? Nearly, a delta call covers new data and changed files while team messages waiting in an inbox require a separate check.

What is the fastest way to give a loop good answers to all three questions? Point it at a context layer such as Fulcra, where one delta call plus an inbox check covers the routine.