The word is doing too much work
People call a model, a workflow and a whole product an “agent.” The label is not useful until we can point to what the system is allowed to do.
A bounded tool-using agent is simply a small system with a loop. It reads a defined input, gathers permitted evidence, asks a model for a proposal, validates that proposal, uses only approved tools, records what happened, then stops or asks a human. It is not a promise of autonomy.
input → observe → propose → validate → act or ask → record → stop
↑ │
└──── bounded retry ──────┘
The model proposes. The harness runs the loop. Policy decides what is allowed. The tool performs a real effect. State and events preserve the evidence. Keep those jobs separate and the system remains explainable.
Boundaries are the feature
“Investigate this incident and open a ticket if the evidence is strong” is bounded. It has a purpose, a limited set of evidence sources, a small set of allowed outcomes and a human checkpoint before a consequential change.
“Keep our platform healthy” is a slogan. A model cannot turn a vague ambition into safe authority.
Start small: one goal, one loop, a few tools, an explicit stop condition. A workflow is still the better answer when every branch can be stated as a rule.
Try it
From the cloned Workbench folder, run:
workbench advanced
It runs one real, local proposal cycle. The fixture provider receives only the selected synthetic evidence, returns a proposal, and the harness validates it. The proposed open_ticket action then stops at a human approval boundary. It does not choose the investigation route, change workflow state or deploy anything.
No API key is required. To use a Groq model after you have deliberately configured GROQ_API_KEY, run workbench advanced --provider groq. It is still only a proposal writer—not the owner of your system.
Keep this with you
An agent is a control loop with authority. Design the authority before you admire the loop.