LIWLuttrell Intelligence WorksPractical AI training for real work

agents-and-architecture

Agent Boundaries and Human Review

Understand when an agent loop is justified and where human checkpoints should remain.

intermediate45 minutesbuilder

Agent patterns become valuable when tools, memory, and iterative planning help complete a task that would otherwise stall. They become dangerous when we skip the review discipline that complexity demands.

The first architecture question is not “how autonomous can this be?” It is “what should the system be allowed to do, and what evidence will prove it did the right thing?” Boundaries answer that question.

What Makes Something an Agent Workflow

An agent workflow usually has four moving parts:

  1. A model that interprets the goal and decides what to do next.
  2. Tools that let the model read, search, write, call APIs, or run commands.
  3. State that carries progress, context, and artifacts across steps.
  4. Review gates that decide whether the output can be trusted or acted on.

A simple chat prompt may only produce text. An agent workflow can change the world around it. It can fetch source material, create files, update tickets, call services, or trigger follow-up work.

That extra capability is useful, but it expands the blast radius. If the agent misunderstands the task, uses stale context, or trusts an unsupported claim, the mistake can move from a draft into a system of record.

Boundaries keep that from happening silently.

Boundary Types

Useful agent boundaries are concrete. “Be careful” is not a boundary. “Read-only access to these three repositories and no external messages without approval” is a boundary.

Data Boundaries

Data boundaries define what the workflow can read and what it must not expose.

Examples:

  • read only approved source folders
  • exclude private messages, customer records, credentials, or financial data
  • use sanitized examples instead of real client details
  • return links or references instead of copying sensitive source text

Data boundaries matter because models are good at blending context. If restricted material enters the prompt, the output may reuse it in places it does not belong.

Tool Boundaries

Tool boundaries define what the workflow can do.

Examples:

  • read files but do not write them
  • create draft tickets but do not submit them
  • run tests but do not deploy
  • search public docs but do not send email

The risk is not just that a tool call fails. The risk is that it succeeds at the wrong thing.

Action Boundaries

Action boundaries define which operations require approval.

Examples:

  • publishing content
  • sending a message
  • updating a production record
  • changing user access
  • spending money
  • deleting or replacing data

The more consequential the action, the more explicit the gate should be.

Cost and Time Boundaries

Agent workflows can loop, retry, fan out, or process more data than expected.

Examples:

  • maximum number of model calls
  • maximum number of retry attempts
  • maximum parallel workers
  • maximum runtime
  • stop condition when the workflow cannot prove progress

Cost controls are not just budget controls. They are also reliability controls. A workflow that keeps running after it is stuck is usually hiding a design problem.

Escalation Boundaries

Escalation boundaries define when the agent stops and asks for help.

Examples:

  • required source is missing
  • the same validation failure happens twice
  • the task requires broader permissions
  • the output includes unverifiable claims
  • the next step would affect an external person or system

A good agent is allowed to stop. A bad one improvises past the point where it still has enough authority or context to be trusted.

Autonomy Tiers

Think in tiers rather than a single yes/no answer.

Tier 1: Read-Only Assistant

The agent can inspect, summarize, classify, and recommend. It cannot write to systems of record or send messages.

Use this tier when:

  • the workflow is new
  • source boundaries are still being tested
  • output quality is not yet measured
  • the task involves sensitive or consequential material

This is the safest place to start.

Tier 2: Draft Producer

The agent can create draft artifacts, but a person reviews before anything is published, sent, merged, or applied.

Use this tier when:

  • the task is repeatable
  • a human can review the output efficiently
  • the cost of a bad draft is low
  • the final action still needs judgment

Most workplace AI workflows should live here for a while.

Tier 3: Approval-Gated Operator

The agent can prepare an action and queue it for approval. The approval step is explicit and auditable.

Use this tier when:

  • the action is structured
  • approval criteria are known
  • the system can show exactly what will change
  • rollback or correction is possible

Examples include creating a draft ticket, staging a content update, or preparing a pull request.

Tier 4: Bounded Autonomous Operator

The agent can complete a narrow action without human approval, but only inside a tight envelope.

Use this tier only when:

  • the task is low-risk and reversible
  • inputs and outputs are well understood
  • monitoring exists
  • failure handling is explicit
  • the system logs what happened

Do not jump here because the demo looked good once.

Worked Example: Document Triage Agent

Imagine a team receives a shared folder of documents and wants an agent to identify which ones look like policies, procedures, project notes, or duplicates.

Weak boundary design:

  • The agent can read the folder.
  • It can organize files however it wants.
  • It reports what it changed.

This sounds efficient, but it is risky. A misclassification could move or rename important files. The agent may not know which folder contains drafts, records, or restricted material.

Stronger boundary design:

  • The agent has read-only access to the source folder.
  • It writes a classification report to a separate review folder.
  • The report includes file path, proposed category, confidence, and reason.
  • It flags low-confidence items instead of guessing.
  • A person reviews the report before any files are moved.
  • A second tool, not the classifier, performs approved moves from the reviewed report.

The stronger version separates analysis from action. That separation is what makes the workflow reviewable.

Boundary Anti-Patterns

Watch for these patterns during design review.

Silent Write-Back

The agent updates the system of record while presenting the change as a draft or recommendation.

Fix: make write operations separate, visible, and approval-gated unless the action is low-risk and preapproved.

Unbounded Tool Access

The agent has every available tool because “it might need them.”

Fix: give the agent only the tools required for the job. If one workflow needs many unrelated tools, split the workflow.

God Context

The orchestrator carries all source content, all intermediate output, and all instructions in one growing context.

Fix: use artifact references and summaries. Keep source material in durable storage and pass only what each step needs.

Autonomy as a Shortcut Around Process

The agent skips review, QA, or approvals because the team wants velocity.

Fix: treat review gates as part of the architecture. If the organization would require review from a human worker, the agent does not magically remove that requirement.

Compact Design Checklist

Before increasing autonomy, answer these questions:

  • What exact sources may the agent read?
  • What exact tools may it use?
  • What actions are forbidden?
  • What actions require approval?
  • What does the agent write, and where?
  • What proof shows the task is complete?
  • What happens after two failures?
  • Who reviews high-impact or low-confidence output?
  • How is cost or runtime bounded?
  • How can the workflow be resumed after interruption?

If any answer is vague, keep the workflow in a lower autonomy tier.

Knowledge Check

Review each scenario and choose the safest autonomy tier.

  1. Summarizing a public product announcement for an internal reading list.
  2. Drafting a customer email that explains a missed deadline.
  3. Creating remediation tickets from an architecture drift report.
  4. Renaming files in a shared legal folder based on document content.
  5. Producing a weekly list of public AI articles for a team newsletter.

For each one, identify:

  • the data boundary
  • the action boundary
  • the human review point
  • the evidence required before completion

The goal is not to make everything manual. The goal is to automate only inside a boundary that the team can explain, monitor, and defend.

Practice

Draft a boundary packet before choosing autonomy

A team wants an agent to triage incoming work requests, assign urgency, draft a response, and mark routine requests complete. The first proposal says the agent should "handle the queue automatically." Your job is to slow the design down enough to make the boundary visible.

Learner task

Draft a boundary packet that names what the agent may read, what it may write, which actions require approval, what evidence it must save, when it must stop, and the safest autonomy tier for the first release.

Expected answer shape

  • Data boundary
  • Tool and write boundary
  • Human review gate
  • Stop or escalation conditions
  • Completion evidence
  • Recommended autonomy tier

Rubric

  • Separates reading, drafting, writing, and external action instead of treating them as one permission.
  • Names at least one explicit human review gate before a consequential action.
  • Includes stop conditions for missing source material, low confidence, or boundary violations.
  • Requires evidence that a reviewer can inspect before completion.
  • Chooses the lowest useful autonomy tier for a first release.
Compare with sample answer

Data boundary: the agent may read approved request fields, prior public knowledge-base answers, and the current queue status. It may not read private messages, credentials, customer records outside the request, or financial material. Tool and write boundary: it may classify the request, draft a response, and create a reviewer packet. It may not send the response, close the request, change priority, or update a system of record without approval. Human review gate: a reviewer approves any outbound response, high-urgency label, closure, or escalation. Stop conditions: missing source data, conflicting policy, low confidence, request for external action, or two failed validation attempts. Completion evidence: source request id, classification rationale, draft response, confidence, reviewer decision, and validation result. Recommended tier: draft-only for the first release, with approval-gated closure considered only after review data shows the boundaries are reliable.

Common mistakes

  • Starting at bounded autonomy because the workflow sounds routine.
  • Allowing the agent to both classify and close work without independent review.
  • Forgetting to define what source material is allowed.
  • Treating confidence as evidence instead of requiring a reviewable packet.

Self-check

Why is draft-only usually safer than bounded autonomy for a first release?

Answer: Draft-only lets the team collect review data and failure examples before the agent can make consequential changes.

Early runs should prove the boundary and expose failure patterns before write or external-effect authority expands.

What should the agent do when required source material is missing?

Answer: Stop, mark the output incomplete or blocked, and record what source is missing for reviewer follow-up.

Missing source material is a stop condition, not permission for the agent to infer facts.

Completion evidence

  • Draft a boundary packet with read, write, review, stop, and evidence sections.
  • Compare your packet against the sample answer and rubric.
  • Name the first-release autonomy tier and one condition that would justify expanding it later.
  • Identify one action the agent must not perform without approval.

Objectives

  • Identify the moving parts in a tool-using agent workflow.
  • Choose review checkpoints before automation expands.
  • Explain why some decisions should remain human-led.
  • Define data, action, cost, and escalation boundaries for a proposed agent workflow.
  • Draft a boundary packet for a proposed agent workflow before assigning an autonomy tier.

Key takeaways

  • More autonomy increases verification needs.
  • Agent design is an operations problem as much as a coding problem.
  • A boundary is useful only when it is explicit, observable, and enforceable.