Agents and tool use

Lesson preparation and outcomes

Prerequisites: Validated dictionaries, exceptions and status handling.

By the end, you can: Build an executor boundary and distinguish workflow ordering from agent selection.

Worked scenario and practice feedback

A mock model requests read_document for doc-1 as guest and then asserts success. The dispatcher denies access; the harness cannot cite the document because no successful observation exists. A second run repeats allowed reads and must stop at the call budget.

Guided and independent practice: Use the dispatcher and mock loop below. Independently inject cancellation and a tool result claiming new permission.

Answer criteria: No unlisted action, invalid arguments or unauthorized read executes; total-call/deadline/no-progress limits and terminal status are visible. If the local pack or interpreter is unavailable, trace the synthetic input, expected output and failure guard on paper; label execution unverified. Required practice uses no paid API calls, accounts, purchase, operational data or actual deployment.

An agentic harness permits model-selected actions within enforced boundaries. Learn when selection helps the task and how to stop unsupported or unauthorized actions.

Part 1 What an agent actually is.

An agentic harness lets a model select a next action from observations while application code governs what can execute. A goal can be precise, one tool can be sufficient, and a successful run may finish after one action. Tool count, vague goals and minimum iteration counts do not define agency.

A fixed workflow chooses its transitions in code. An agent chooses among permitted transitions using a model. Use the fixed workflow when order and rules are known; use agentic selection when observations genuinely change the next useful action. Both need bounded failure behavior.

Start with the task and unacceptable outcome. Select a model that can handle the required input and tool protocol in the approved deployment. Then design the harness: available tools, arguments, state, budgets, observations, termination and human decisions. The workflow reference separates model capability, deployment location and harness behavior. A frontier model can be used in a constrained workflow; a local model can be used in an agent; neither label settles quality or authorization.

Part 2 Validate tool requests before dispatch.

A model tool request is data to validate, not permission to act. Give each tool an exact schema with required fields, permitted enums, bounded strings and additionalProperties: false where supported. Validate again in application code. Use the authenticated actor and resource policy outside the prompt.

This complete offline dispatcher demonstrates the boundary. It makes no model, network or file call.

CATALOG = {"doc-1": "Workshop starts at 09:00."}

def execute(call, actor):
    if not isinstance(call, dict):
        return {"status": "error", "error": "invalid_arguments"}
    if call.get("name") != "read_document":
        return {"status": "error", "error": "unknown_tool"}
    args = call.get("arguments", {})
    if not isinstance(args, dict) or set(args) != {"document_id"} or set(call) != {"name", "arguments"}:
        return {"status": "error", "error": "invalid_arguments"}
    document_id = args["document_id"]
    if not isinstance(document_id, str) or not document_id.strip() or len(document_id) > 40:
        return {"status": "error", "error": "invalid_identifier"}
    if actor != "learner" or document_id not in CATALOG:
        return {"status": "error", "error": "denied"}
    return {"status": "complete", "source_id": document_id,
            "text": CATALOG[document_id]}

call = {"name": "read_document", "arguments": {"document_id": "doc-1"}}
assert execute(call, "learner")["status"] == "complete"
assert execute(call, "guest")["error"] == "denied"
assert execute({"name": "delete_document"}, "learner")["error"] == "unknown_tool"
for malformed in (None, [], {"name": "read_document", "arguments": None},
                  {"name": "read_document", "arguments": ["document_id"]}):
    assert execute(malformed, "learner")["error"] == "invalid_arguments"
print("normal, denied, unknown-tool and malformed-request checks passed")

A real loop also normalizes complete, partial, refusal, cancellation and error outcomes, preserves tool-call IDs and required provider state, validates result content and stops on deadlines, exhausted budgets or repeated lack of progress. Never assume the final block is text. Cap total tool calls as well as steps because one response may request several tools.

MCP standardizes exchange between clients and tool servers; it does not grant permission or make returned content trustworthy. Server authentication, least privilege, resource authorization, schema validation and egress policy remain application responsibilities. For consequential actions require an approval bound to actor, exact action, arguments/resource version and expiry; a changed request invalidates it. Use idempotency keys, cancellation checks and recovery records before retrying any action with effects.

Part 3 Where agents earn their cost.

Agentic selection helps a diagnostic task when the next inspection depends on the result of the previous one. A documentation investigation may need a search, then a source read, then a targeted follow-up. A comparison of two already supplied documents may only need one generation call. A known form-processing sequence may be simpler as a deterministic workflow.

Compare a fixed workflow and an agent on the same model, allowed tools, input cases and budgets. Compare models using the same harness. If you change model and harness together, you cannot attribute the result. Record success, unsupported claims, denial behavior, human interventions, tool counts and completion time; do not infer efficiency from a impressive transcript.

Part 4 Where agents fail and what to do about it.

Common failures require code-level controls:

• Wandering: enforce a deadline, call cap and no-progress counter; return a partial result with unresolved items.
• Tool misuse: reject invalid arguments before execution and return a typed repairable error; do not expand the tool list.
• Fabricated success: verify result status and evidence IDs before claiming completion.
• Wrong ordering: make prerequisites explicit in a state machine; parallelize only independent reads.
• Duplicate effects after a timeout: reconcile recorded action status using an idempotency key; do not blindly retry.
• Context loss: persist the task, decisions, evidence IDs and pending actions outside the model. Compaction is lossy; retain approvals and policy outside summaries.

Prompt wording can guide decisions but cannot replace enforcement. If the harness cannot verify a required outcome, stop and ask the named human decision owner. A fallback is safe only if evaluated for that task and deployment.

Interface/reference limits

Use the workflow reference to connect task, model, deployment, harness/tools, evidence and the responsible human decision. Synthetic demonstrations establish only the stated tested conditions.

Primary source checked October 2, 2026: OpenAI function calling.