This post is for CTOs and product leaders deciding how much autonomy to give an agent that will touch production systems. It sets out the six constraints we put on every agent we ship, and the narrow set of cases where more autonomy actually pays.
The autonomous-agent hype cycle peaked sometime in 2024 and is, in our experience, still wasting engineering hours in 2026. The pattern is familiar: someone reads about AutoGPT or BabyAGI, builds an open-loop agent that decides its own next step, runs it on a real task, and discovers that within a dozen iterations the agent has reasoned itself into a confidently wrong action that hits production and breaks something expensive.
The shippable agents we run in production for telco, insurance, healthcare, legal, and e-commerce clients are not autonomous. They are bounded. The agent decides what to do at each step, but the space of "what" is finite, audited, and reversible. Here is what bounded actually looks like in AI agent development, and why it ships when autonomous does not.
1. Tools are an explicit whitelist, not an open API
The first failure mode of autonomous agents is that they can call any tool the framework exposes, in any combination, in any order. That gives the agent a combinatorial action space that is impossible to test exhaustively. The bounded version: every tool is a typed function with explicit input and output schemas, and the agent's system prompt only enumerates the tools that are valid for the current conversation state.
In our telco SMS deployment, the agent has access to four tools at any given moment: lookup_account, check_balance, change_plan, and escalate_to_human. It does not have access to refund_customer, suspend_account, or modify_billing, even though those tools exist in the broader system, because the user's conversation has not been routed through the authentication and approval gates that unlock them. The tool set is a function of state, not a static configuration.
2. Recursion is bounded, not open-ended
An agent that can call itself indefinitely is an agent that will, on some unlucky distribution of inputs, call itself 40 times and run up a thousand-dollar LLM bill on a single user turn. Bounded agents have a maximum recursion depth, typically 3 to 5 sub-steps per user turn, and a hard timeout. When the bound is hit, the agent escalates to a human or returns a controlled partial answer with an explicit "I need help with this" flag.
3. Every action is logged with the agent's reasoning
An autonomous agent that takes an unexpected action is a debugging nightmare because the action lives in production but the reasoning lived in the agent's scratch-thought, which was not saved. Bounded agents log every step: the agent's reasoning text, the tool it chose, the tool's input, the tool's output, the agent's interpretation of that output, and the next step.
This is non-negotiable for regulated workloads. Our healthcare RAG agent logs every retrieval query, every cited document, every refusal, and every model response to a tamper-evident audit log. When a clinician asks "why did the agent say that?" three weeks later, the answer is reconstructible to the second. Without it, every model upgrade is a compliance question.
4. Human approval gates for high-stakes actions
Some actions are reversible (sending a confirmation SMS, surfacing a knowledge-base answer). Some are not (charging a customer, posting a journal entry, deleting a record). Bounded agents categorize tools by reversibility and route the irreversible ones through an explicit human approval gate before execution.
The approval gate can be synchronous (the user must click a button to confirm) or asynchronous (a back-office team approves overnight). What it cannot be, in our experience, is implicit. "The model has confidence X so we just do the thing" is the design that breaks loudly the first time the model's confidence is wrong.
5. Refusal is a first-class action
Autonomous agents are typically trained, implicitly, by their reward models, to produce an answer. They do not refuse. Bounded agents are explicitly given "I cannot help with this" as a valid action, and the eval harness measures refusal correctness alongside answer correctness. A correct refusal on an out-of-scope query is just as valuable as a correct answer on an in-scope one.
Refusal protects against three failure modes at once: hallucination (the agent invents an answer because nothing relevant was retrieved), scope creep (the agent tries to handle a question that belongs to a different team), and prompt injection (the agent gets convinced to do something it should not by adversarial input). All three become observable when refusal is logged.
6. The eval suite gates every change to the agent
Bounded agents have a golden eval set: a few hundred representative conversation traces with expected actions, expected refusals, and expected tool-call sequences. Every prompt change, every model swap, every new tool addition runs against the eval set, and the deployment is blocked if any metric regresses past threshold.
This is the boring, unglamorous discipline that separates agents that ship from agents that demo. Without it, you discover regressions when users find them. With it, you discover them in CI and never ship them. It is the single highest-leverage investment in agent reliability and the single most common one to skip in early development.
Where autonomous still wins
There is a narrow band of problems, such as open-ended research tasks, exploratory data analysis, and creative generation, where giving the agent more autonomy genuinely produces better outcomes than constraining it. The pattern there is to run the autonomous agent inside a sandbox, with no production-write tool access, and treat its output as a draft to be reviewed rather than an action to be executed.
Most production agents are not in that band. They are doing bounded business automation work: routing customer service tickets, processing invoices, booking appointments, or triaging clinical questions. For those, bounded beats autonomous every time. Ship the bounded version, instrument it heavily, and only introduce autonomy where the eval set proves it adds value.
If you are scoping an agent that will touch production systems and want a second opinion on where the bounds should sit, talk to our engineering team. We will tell you which tools need approval gates, where the recursion cap belongs, and what the first eval set should contain.
Frequently asked questions
What is a bounded agent?
An agent whose action space is finite, audited, and reversible. It still decides what to do at each step, but only from a typed tool whitelist that depends on conversation state, with a hard recursion cap, full logging, approval gates for irreversible actions, and refusal as a valid outcome.
How deep should an agent's recursion go?
Typically 3 to 5 sub-steps per user turn, plus a hard timeout. When the cap is hit the agent should escalate to a human or return a controlled partial answer, so that edge cases surface instead of failing silently.
When does an autonomous agent make sense?
For open-ended research, exploratory analysis, and creative generation, run inside a sandbox with no production-write tool access. Its output is treated as a draft for review, not an action to execute.