> ## Documentation Index
> Fetch the complete documentation index at: https://agentconcepts.io/llms.txt
> Use this file to discover all available pages before exploring further.
# close-the-loop
> A return signal travels back to the specific party that initiated an action, confirming to that originator that the action landed — receipt, status, or acknowledgment routed to the requester, not merely to the system at large. The originator-as-recipient constraint is the concept.
computer-science medicine-and-health psychology
# Close-the-loop
## Description
To close the loop is to route a return signal back to the specific party that initiated an action, confirming *to that originator* that the action landed. The defining constraint is the recipient's identity: the confirmation must reach the requester — the person or system that asked — not merely be emitted into the system, logged, or broadcast. Receipt, read-back, status, or completion-acknowledgment addressed to the initiator is closing the loop; the same information sent anywhere else is not.
Four roles compose the shape. The *originator* is the initiating party who needs to learn the action landed — the required recipient of the return. The *action* is the request, instruction, or task whose landing is in question. The *return signal* is the acknowledgment, read-back, or status update that travels back specifically to the originator; its absence is the open-loop pathology. The *routing constraint* is the requirement that the return be addressed to the originator rather than merely produced — the feature that separates closing the loop from logging, broadcasting, or feeding back into the system at large.
The diagnostic question — *does the party that initiated this action receive confirmation that it landed?* — places the concept on a sharp three-way boundary. It is a specialization of [feedback-loop](/concepts/feedback-loop): generic feedback returns output to influence input, but says nothing about *who* receives it, while close-the-loop pins the recipient to the originator. And it is distinct from [loop-completion](/concepts/loop-completion), which is a meta-diagnostic about whether a working, post-coherent journey is structurally complete; close-the-loop is the object-level protocol that fixes where the return goes. The same word "close the loop" is used loosely for both, which is why the originator-as-recipient constraint has to do the discriminating work.
The shape is the explicit doctrine of high-reliability communication. Aviation crew-resource-management mandates read-back/hear-back — the receiver of an instruction repeats it back so the originator confirms it was heard correctly. Clinical laboratories require critical-value callback — a dangerously abnormal result is phoned directly back to the ordering clinician, not merely posted to a chart. Network protocols send an ACK back to the sender. Military voice procedure requires "acknowledge, over." In each, the failure mode is identical and silent: the action was dispatched, something may have received it, but the *originator never learns it landed*, and the absence of that specific return is what causes the harm.
## Triggers
**User-initiated:** User describes an action dispatched without the initiator being told it landed, or invokes read-back / acknowledgment / "did this get back to whoever asked?" Vocabulary cues: "close the loop," "read-back," "acknowledge receipt," "confirm you got this," "status back to the requester," "callback."
**Agent-initiated:** Agent notices an action whose initiator receives no confirmation of receipt or completion — the return either does not exist or is routed somewhere other than the originator. Candidate inference: "the loop isn't closed back to the requester — what acknowledgment should return to the initiator specifically, and does it?"
**Situation-shape signals:** A request filed into a system with no acknowledgment to the filer. An instruction passed down a chain with no read-back. A task dispatched to a worker with no completion-status returned to the dispatcher. Any place where "I sent it, but did *they* ever hear back?" is the worry.
## Exclusions
* **Generic feedback to the system, not the originator** — when output influences future input but the return need not reach the initiating party, the shape is [feedback-loop](/concepts/feedback-loop). Close-the-loop fixes the recipient to the requester.
* **The coherence-gap diagnostic** — when the question is whether a post-coherent journey is structurally complete, the shape is [loop-completion](/concepts/loop-completion). Close-the-loop is the narrower object-level protocol that the initiator is told the action landed.
* **Acknowledgment to a third party or broadcast** — receipt confirmed to a monitor, audit log, or the world rather than the originator does not meet the return-to-the-requester constraint. A public status page is not closing the loop with the person who asked.
* **One-shot fire-and-forget with no expected confirmation** — when an action is intentionally dispatched without expectation of acknowledgment, there is no loop to close back to an originator.
## Structure
## Relationships
* [feedback-loop](/concepts/feedback-loop) — close-the-loop specializes generic feedback by pinning the recipient to the originator; the added recipient-identity constraint is what makes it a communication-acknowledgment protocol rather than control feedback.
* [loop-completion](/concepts/loop-completion) — the contrast that earns the concept its keep: loop-completion is a meta-diagnostic about a post-coherent journey's structural completeness; close-the-loop is the object-level protocol fixing the return's destination as the requester. An external read once flat-aliased the two; the originator-as-recipient constraint is the distinction.
* [doctrine](/concepts/doctrine) — high-reliability fields (aviation read-back, clinical critical-value callback, military voice procedure) encode close-the-loop as standing doctrine, making the return-to-the-originator step mandatory because its omission is a silent, high-cost failure.
## Examples
Salas, Sims, and Burke identify closed-loop communication as one of the core coordinating mechanisms of effective teams. The protocol has three beats: a sender transmits a message, the receiver acknowledges it (often by reading it back), and the *original sender confirms* that the message was received and understood as intended. The third beat is the defining one — the loop returns to the party who initiated the communication, who alone can verify that the message landed correctly. In aviation and surgical-team training this is taught as read-back / hear-back, and its omission is a documented source of coordination failures.
**Inference**: This is the clearest statement of the originator-as-recipient constraint that distinguishes close-the-loop from generic feedback. The acknowledgment is not merely produced; it returns specifically to the initiator, who closes the loop by confirming the read-back. A team that broadcasts confirmations to a log rather than back to the sender has not closed the loop in this sense — the sender, the one party who needs to know the message landed, never finds out.
The Joint Commission requires that critical test results — dangerously abnormal lab values — be reported on a timely basis to the licensed caregiver responsible for the patient. The standard is satisfied not by posting the result to the chart but by an active callback that reaches the *ordering or responsible clinician* specifically, who acknowledges receipt. The loop closes back to the party who initiated the order and who must act on the result; a critical potassium value that lands only in a database, with no clinician confirming receipt, is the open-loop failure the requirement exists to prevent.
**Inference**: A canonical institutional instance of the routing constraint. The information is not merely recorded or broadcast — it is routed back to the specific originator (the ordering clinician) with required acknowledgment. This exhibits why close-the-loop is its own primitive rather than generic feedback: the lab result *does* enter the system either way, but only the return-to-the-originator-with-acknowledgment step prevents the silent, high-cost failure of a critical value that no one acts on.
TCP's reliability rests on acknowledgments that return to the sender. When a host transmits a segment, it retains it until the receiver sends back an ACK referencing the sequence numbers it has successfully received. The acknowledgment is addressed *to the originator of the data* — it is the sender, not the network or a monitor, that needs to learn the segment arrived, and the sender retransmits if no ACK returns within a timeout. The loop is closed back to the party that initiated the transmission, and unacknowledged data is the protocol's signal that the loop is still open.
**Inference**: TCP is the engineered, fully-formalized instance of the originator-as-recipient constraint. The ACK is not a generic feedback signal influencing the system; it is routed specifically back to the sender, who is the one party able to decide whether to retransmit. It also cleanly marks the fire-and-forget exclusion: UDP, which sends without expecting acknowledgment, has no loop to close back to an originator — the difference between the two protocols is precisely whether close-the-loop applies.