Bounded vs Open-Ended Agent Tasks: Choosing the Right Shape

Bounded tasks succeed in production. Open-ended ones rarely do. The shape test that tells you which kind you have, and how to convert open-ended into bounded.

The shape test

A bounded task has three properties: a clear input contract, a clear success criterion, and a finite set of legal actions. "Triage this alert and return a hypothesis" is bounded. "Improve our reliability" is not.

If you cannot describe the success criterion in one sentence and the action set as a list, the task is open-ended. Open-ended tasks are not bad, but they require different infrastructure: stronger evals, tighter bounds, more human checkpoints.

When in doubt, treat the task as more open-ended than it looks. Optimism about boundedness is the most common cause of agent failure in production.

Converting open-ended to bounded

Most open-ended tasks decompose into bounded sub-tasks. "Investigate this incident" decomposes into "identify the affected service," "identify the proximate cause," "propose a remediation." Each sub-task is bounded.

Decompose at design time, not at runtime. The agent should know it is doing sub-task 2 of 3, not figure it out as it goes. Runtime decomposition is where open-ended tasks fail; the agent loses track of where it is.

Each sub-task gets its own prompt, its own tools, and its own success criterion. The orchestrator that strings them together is code, not prompt. This is the reliable pattern.

Why bounded tasks turn open-ended

A bounded task starts succeeding. Stakeholders ask for one more thing. Then another. The contract loosens. Six months later the task is open-ended and nobody noticed.

Resist scope creep at the contract level. "This agent does X" is the contract. Adding Y is not a tweak; it is a new agent. Even if it is a small Y. The discipline of "new agent for new task" is what keeps individual agents reliable.

Track the contract as code: the input schema, the output schema, the action set. When someone proposes a change, they are proposing a contract change. Treat it like an API change: deprecate, version, migrate.

Different infra for different shapes

Bounded tasks fit in stateless functions. Cheap to run, easy to scale, simple to monitor. The infrastructure is the same as any other API endpoint.

Open-ended tasks need workflow infrastructure: state, checkpointing, human-in-the-loop, replay. The infra cost is real; budget for it. Trying to run open-ended tasks on bounded infra produces fragile agents.

Pick the infra to match the shape. Mismatched infra (bounded task on workflow infra, or open-ended task on stateless) wastes money and reliability.

When to graduate from bounded to open-ended

Some agents start bounded and need to grow into open-ended. The trigger: the bounded shape leaves too much value on the table because real incidents do not fit the contract.

When you graduate, do it explicitly. Acknowledge the agent is now open-ended. Add the workflow infrastructure. Add the human-in-the-loop checkpoints. Refactor the evals.

Most agents do not need to graduate. Most stay bounded forever, doing one thing well, and that is the right outcome. Aspiring to open-ended is not the goal; reliable value is.

What to do this week

List your agents. For each, write the success criterion in one sentence and the action set as a bulleted list. The ones you cannot do are the open-ended agents; check that they have the workflow infrastructure to match. The ones you can do are bounded; check that nobody has been quietly extending them.