Multi-Step Workflows and Bounded Autonomy
Learning Objectives
- You understand how tool use enables multi-step workflows.
- You know why multi-step systems need explicit boundaries and review points.
- You can identify guardrails that reduce unnecessary risk.
From single action to workflow
Once a model can choose and use tools, it can also participate in multi-step workflows.
For example, an assistant might:
- inspect the user question,
- decide to retrieve a local issue,
- count related issues by status,
- and only then return a final explanation.
This is still a small workflow, but it is already more than a one-shot prompt.
Workflow design is software design
A multi-step agentic workflow is still software. That means it benefits from the same kinds of design questions as any other program:
Which steps are allowed? Which steps are deterministic? Which steps can fail? Where should the workflow stop and ask for help?
If these questions are left implicit, the system becomes difficult to reason about and difficult to trust.
Suppose that an assistant can inspect a bug report, look up related issues, and draft a response. Even in that small example, the workflow already has structure. The lookup step is deterministic. The drafting step is model-based. The final action may or may not require a person to review it. Good workflow design makes those differences visible.
Useful guardrails
Common guardrails in bounded-autonomy systems include limiting the available tools, validating tool arguments before execution, requiring confirmation before sensitive actions, limiting the number of tool calls in one loop, and keeping logs or transcripts for later review.
These measures do not make the system perfect, but they make its behavior more inspectable and easier to debug.
Notice that these are mostly ordinary software design choices. The system becomes safer not because the model has become trustworthy in the abstract, but because the surrounding application narrows the places where a bad decision can have consequences.
Keep humans in charge of consequences
If a workflow can affect data, users, or infrastructure, the application should be designed so that the model does not silently cross important boundaries.
That often means one of three patterns. The model can recommend an action, but a human approves it. The model can act only on low-risk tools. Or the workflow can be split into read-only and write-capable phases so that the risky part stays under tighter control.
Bounded autonomy is not only an implementation detail. It is a product and safety decision. The right boundary depends on what the system can do and what would happen if it made a wrong choice.
Start with narrow workflows
For educational examples and many real systems, narrow workflows are better than general ones. A small, explicit workflow is easier to explain, easier to test, and easier to improve later.
This is also why the tutorial chapter that follows uses a deliberately small loop. The assistant can decide whether to call a tool, the application executes it, and the model then answers. That is not a full general-purpose workflow engine. It is an intentionally narrow example that makes the boundary between model reasoning and application control easy to see.
Research examples in this area include ReAct: Synergizing Reasoning and Acting in Language Models, SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering, and the newer comparison point Agentless: Demystifying LLM-based Software Engineering Agents, which argues that simpler and more bounded approaches can still be highly competitive.