How AI's Actually Work — HAAW

The Agent Loop in Slow Motion

One Goal, Several Inferences, Tools, State Changes and Decisions

One Goal Is Not One Inference

A normal chat response may require one model-generation episode. An agentic job can require a chain of model inferences separated by external actions and observations. The word agent describes the larger loop—not a new organ hidden inside the transformer.

GOAL ↓ INFERENCE 1 → ACTION 1 → RESULT 1 ↓ INFERENCE 2 → ACTION 2 → RESULT 2 ↓ INFERENCE 3 → ... ↓ DONE

Our Example Goal

We will use a sysadmin problem because the steps are concrete and familiar:

GOAL: "Find out why the HAAW web server is unavailable. Do not change the system. Report the likely cause and evidence."

That final constraint matters. The agent is authorized to inspect, not repair.

The Available Capability Array

The surrounding system exposes a set of permitted capabilities:

TOOLS / CAPABILITIES [0] ping_host(host) [1] service_status(service) [2] listening_ports() [3] read_log(path, lines) [4] config_test(service) [5] dns_lookup(name) [6] http_request(url) NOT AVAILABLE: restart_service() edit_file() delete_file() shell_unrestricted()

The agent does not possess unlimited machine access. It can choose only among capabilities the system makes available.

Sources and Actions Are Different

Information Source

Logs, databases, documents, search results, telemetry.

Computation

Calculator, parser, compiler, test runner.

Observation

Ping, status checks, sensors, health endpoints.

Action

Edit, restart, send, create, delete, purchase, deploy.

All can be “tools,” but their consequences and permission requirements differ dramatically.

State 0 — Before Anything Happens

STATE 0 goal: diagnose HAAW outage constraints: read-only report evidence do not repair known: user says site is unavailable unknown: host reachability service state listening sockets logs configuration health available tools: ping, status, ports, logs, config test, DNS, HTTP

This state is not necessarily one literal data structure. It is a conceptual description of the information available to the agent system at this point.

Inference 1 — Choose the First Observation

The model receives the goal, constraints, current state and tool definitions as usable context.

MODEL INFERENCE input: goal + constraints + state + tool descriptions model-directed output: request ping_host("haaw-server")

Underneath that decision, the familiar model machinery still runs:

Tokenizer → Token / Token ID → Embedding Lookup → Embedding Vector → Transformer → Logits → structured output

The Request Is Not Yet the Action

MODEL REQUEST ping_host("haaw-server") ↓ ORCHESTRATOR • is this a known tool? • are arguments valid? • is it permitted? ↓ APPROVED ↓ TOOL EXECUTES

The orchestrator creates a control boundary between generated model output and external execution.

Observation 1

TOOL: ping_host("haaw-server") RESULT: host reachable latency: 1.2 ms

The result returns to the agent system. We now have new evidence.

State 1 — Something Changed

STATE 1 known: host reachable still unknown: web service state listening sockets logs configuration health evidence: ping result goal: still unresolved

The machine itself may not have changed. The agent's information state has.

Inference 2 — Use the New Evidence

The next model inference is not identical to the first because its context now contains the ping result.

old context + "host reachable" ↓ new inference ↓ request: service_status("httpd")

Observation 2

TOOL: service_status("httpd") RESULT: state: failed exit status: 1 last transition: 12:41:08

The search space narrows. The host is alive, but the web service has failed.

State 2

known: host reachable httpd failed likely next evidence: service logs configuration test less urgent now: basic host reachability goal: cause still unknown

Inference 3 — Choose a More Specific Tool

MODEL REQUEST: read_log("/var/log/httpd/error_log", 40) ORCHESTRATOR: read-only tool ✓ path permitted ✓ arguments valid ✓ TOOL EXECUTES

Observation 3

LOG RESULT: [12:41:08] AH00526: Syntax error on line 83 of /etc/httpd/conf.d/haaw.conf Invalid command 'ProxyPas'

Now there is strong evidence for a configuration problem—but a log message is still evidence to be checked where possible.

Inference 4 — Verify the Suspected Cause

Rather than immediately reporting the log message as proven cause, the model can choose another capability:

request: config_test("httpd") ↓ result: Syntax error on line 83 Invalid command 'ProxyPas' ↓ exit status: failure

Independent confirmation strengthens the diagnosis.

State 4 — Goal May Be Satisfied

known: host reachable httpd failed error log reports syntax error line 83 config test independently reproduces syntax failure constraint: do not repair remaining question: is evidence sufficient to report likely cause?

Inference 5 — Decide Whether to Stop

MODEL / SYSTEM DECISION: goal = diagnose, not repair evidence = sufficient for likely cause write permission = absent additional action = unnecessary STOP TOOL LOOP generate report

The Final Report

"The host is reachable, but httpd is in a failed state. The error log reports a syntax error at line 83 of /etc/httpd/conf.d/haaw.conf involving 'ProxyPas'. A separate configuration test reproduces the same error. Likely cause: invalid Apache configuration at line 83. No changes were made."

The report is model-generated language, but its central diagnosis is grounded in recorded tool evidence.

Now Replay the Whole Job

Goal + Constraints
↓
Inference 1: choose ping
↓
Tool result: host reachable
↓
State update
↓
Inference 2: inspect httpd
↓
Tool result: failed
↓
State update
↓
Inference 3: read log
↓
Tool result: syntax error
↓
Inference 4: verify configuration
↓
Tool result: same syntax failure
↓
Inference 5: stop and report

Where Exactly Is the Agent?

Not in one component.

The agentic behavior emerges from the cooperating system: model inference + tool descriptions + orchestration + permissions + external capabilities + state + repeated feedback + stopping rules.

MODEL alone ≠ entire agent TOOLS alone ≠ agent ORCHESTRATOR alone ≠ agent COORDINATED LOOP → agentic system behavior

One Goal, Many Model Runs

This is easy to miss from the interface. The user may see one request and one eventual answer:

USER: "Find out why the server is down." ...time passes... ASSISTANT: "The Apache configuration contains a syntax error..."

Between those two visible events may be several separate model inferences and several non-model operations.

The Agent's “Thought” Is Not One Continuous Process

Mechanically, the sequence can look more like:

MODEL RUN ↓ external software ↓ network / OS / tool ↓ result ↓ MODEL RUN ↓ external software ↓ tool ↓ result ↓ MODEL RUN

The model can be completely idle while an external tool is executing.

Waiting Is Part of the System

model requests database query ↓ model inference ends / pauses ↓ database works for 600 ms ↓ result arrives ↓ next model inference begins

Wall-clock time for an agent job therefore includes much more than GPU inference time.

Sequential Dependencies

Our diagnosis had a logical dependency chain:

host reachable? ↓ service state? ↓ error evidence? ↓ verify suspected cause? ↓ report

Some steps only make sense after earlier evidence exists. That makes portions of the workflow inherently sequential.

But Some Work Can Branch

After learning that httpd failed, the system might inspect several independent sources at once:

┌→ read error log ─────┐ httpd failed ────┼→ run config test ────┼→ combine evidence └→ inspect port 443 ────┘

That is concurrent or parallel tool work where the implementation allows it. If the next decision requires all results, the slowest branch can become a synchronization point.

The Capability Array Can Be Dynamic

Not every tool has to be available for every job.

DIAGNOSTIC ROLE: [read logs, status, test config] DEPLOYMENT ROLE: [read + write config, restart, deploy] FINANCE ROLE: [query ledger, calculator] USER-SPECIFIC SESSION: [only tools authorized for this user / task]

The available action space can be restricted by role, environment, user permission, risk level or task.

Choosing a Tool Is Itself a Model Decision

The model may have several plausible routes:

outage ├─ ping? ├─ DNS? ├─ HTTP request? ├─ service status? ├─ logs? └─ port inspection?

Training, current context, tool descriptions and prior observations influence which action is selected. A poor choice wastes time or produces misleading evidence.

The Orchestrator Can Override the Model

MODEL REQUEST: restart_service("httpd") CONSTRAINT: "Do not change the system." ORCHESTRATOR: DENIED RESULT RETURNED TO MODEL: "Operation not permitted in read-only diagnostic session."

The model can propose an action that the larger system refuses to execute.

State Is Not the Same as Memory

Model Weights

Long-lived learned parameters.

Context

Information supplied to the current inference.

Agent State

Goal, progress, observations, artifacts and task status preserved across steps.

External Storage

Files, databases or task records that can persist beyond the current context.

An implementation can move or summarize information among these layers, but HAAW should not collapse them into the word “memory.”

Errors Can Enter at Every Boundary

goal misunderstood ↓ wrong tool chosen ↓ arguments malformed ↓ permission unexpectedly denied ↓ tool fails ↓ result stale or wrong ↓ model misinterprets result ↓ state incorrectly updated ↓ bad next action ↓ bad final report

Agent reliability is therefore a system property, not simply a model benchmark score.

Verification Can Be Built Into the Loop

Our example deliberately did this:

LOG says syntax error ↓ do not immediately stop ↓ CONFIG TEST independently reproduces error ↓ stronger evidence ↓ report likely cause

This is Grounding and Verification operating inside an agent workflow.

Agent Loops Consume Resources

Tokens

Each model inference processes context and generates output.

GPU Time

Each inference consumes accelerator computation.

Tool Time

Searches, APIs, code and external systems have their own latency.

Context

Accumulated results can enlarge the information carried between steps.

Money

Inference, APIs, storage and external services can have direct cost.

Risk

Consequential actions can alter real systems if permissions allow them.

Compaction and Summarization

Long-running jobs can accumulate more state than comfortably fits in active model context.

many tool results many observations many intermediate steps ↓ select / summarize / externalize state ↓ carry forward what future steps need

That process can itself lose information, so provenance and durable records matter when reconstruction is important.

WITNESS View: This Is a Graph

A simple transcript is no longer enough to describe causality.

Inference A │ ├── requested Tool 1 ──→ Result 1 ──┐ │ │ └── requested Tool 2 ──→ Result 2 ──┤ ↓ Inference B │ ↓ Human Approval │ ↓ Action C

The useful record is a graph of events and dependencies: what caused what, what information was available at each decision, and which operations occurred in parallel.

WITNESS Metadata for One Tool Call

event_id parent_inference_id tool_name tool_version arguments request_timestamp authorization_decision execution_start execution_end result_status result_hash / provenance result returned to context next dependent event

Now the recorder can preserve not just chronology but lineage.

The Human Can Be a Node in the Graph

agent proposes consequential action ↓ human receives request ↓ human approves / rejects / modifies ↓ decision recorded ↓ agent continues under new state

Human-in-the-loop is not outside the architecture. It is one of the possible control dependencies in the architecture.

The Agent Loop, Mechanically

An agentic job is a sequence of model inferences separated by external operations and state changes.

The model does not continuously “think” while a tool works. It can request an action, stop or pause, receive the result as new information, and run inference again.

GOAL ↓ INFERENCE ↓ PROPOSED ACTION ↓ VALIDATION / PERMISSION ↓ TOOL EXECUTION ↓ OBSERVATION ↓ STATE UPDATE ↓ NEXT INFERENCE ↓ ... ↓ STOP CONDITION

The agent is the looped system, not merely the transformer.

HAAW Checkpoint

Capability array
The set of tools or operations made available to an agent for a particular task or session.
Goal
The objective supplied to the agentic system.
Constraint
A rule limiting what the system may do while pursuing the goal.
Inference step
One model execution using the current context/state to generate output or select a next action.
Action request
A model-directed proposal to invoke an available capability with specified arguments.
Observation
Information returned from the environment or a tool after an action.
State update
The incorporation of new observations, progress or task information for later steps.
Agent state
Task-specific information preserved across multiple inferences and actions.
Dependency
A relationship in which a later operation requires information or completion from an earlier operation.
Synchronization point
A place where later work must wait for required concurrent or parallel work to finish.
Lineage
The record of how an event, result or decision arose from earlier events and evidence.
Central lesson
One visible user request can expand into many separate model runs, tool executions, observations and state transitions. The agent is the coordinated loop that connects them.