AI agents: agree tasks, actions and boundaries
Judge an AI agent by its actual behaviour: what it reads, what it does and when it stops. A useful quote bounds these capabilities and defines approvals, tests and recurring costs. Start with a concrete task.
Check whether an agent is needed
An agent may choose steps and tools to accomplish a task. A fixed automated workflow follows defined rules; a chatbot may only converse. Describe where flexible decisions are truly needed. More freedom can increase effort, runtime and consequences of errors. Compare a bounded agent with simpler solutions for the same task.
Name permitted tools and actions
Define the goal, applications and permitted data. Reading, preparing drafts and changing records require different permissions. Limit access to necessary functions. An open task description should not implicitly authorise other accounts, services or paid tools. The quote should state those boundaries clearly.
| Action | Clarify the boundary |
|---|---|
| Read | Which records and whose permissions? |
| Prepare | Draft without sending or booking |
| Execute | Specific action, approval and rollback |
Make human approvals specific
Binding, paid or difficult-to-reverse actions need agreed approvals. A person must understand the action and its parameters. Define consequences for refusal, changes and missing responses. Approving a draft does not automatically authorise sending it. Keep previously authorised bounded steps distinct from new actions.
Treat external content as data
Emails, documents and websites may contain instructions that do not come from the requester. The agent should not treat them as new authority. Agree safeguards against forbidden access and disclosure. For personal data, clarify purpose, transparency, retention and risks. A filter or approval prompt alone does not prove complete security.
Plan stopping, recovery and operation
Bound steps, runtime, retries and concurrent tasks to the purpose. Missing information or lack of progress should cause clarification or a stop. After interruption, completed actions must be visible; restarting should avoid duplicates. Define owners, useful logs, manual alternatives and maintenance. Background runs are a separate operating scope.
Test actions and outcomes together
Convincing text does not prove correct actions. Test tool selection, changes, refused actions, stopping limits and human approvals on bounded cases. Use safe test environments and suitable examples. Agree success and failure criteria and remaining limitations. Retest affected cases after changes to models, tools or rules.
Compare bounded usage scenarios
Separate design, integrations, safeguards and testing from model usage, tools, storage and maintenance. One task may trigger multiple calls and retries. Ask for ordinary and difficult scenarios with explicit bounds. Suitable reuse avoids unnecessary work. Alerts do not guarantee a monetary cap; effective provider and application controls must be checked for the agreed operation.
| Cost item | Check the quote |
|---|---|
| Setup | Tasks, tools, safeguards and test cases |
| Execution | Calls, retries and additional services |
| Operation | Bounds, maintenance, owners and rollback |
Checklist and bounded introduction
Describe a concrete task, outcome, applications, data types and the person approving decisions. Add start mode, frequency, allowed actions and timing. No passwords or sensitive raw data in the enquiry. Proceed through suitability assessment, bounded design, quote, pilot, independent review of outcomes and actions, documented approval and handover.
Frequently asked questions
Is every chatbot an agent?
No. A chatbot may only answer; an agent may also choose steps and tools.
When is a fixed workflow enough?
When rules and steps are clearly defined. Additional autonomy should show a benefit for the task.
May an agent act without approval?
Only within explicitly agreed bounded permissions. New or consequential actions need appropriate human approval.
Why are stopping limits needed?
To prevent lack of progress, errors and retries from causing unbounded runtime, costs or changes.
Does a good answer prove correct execution?
No. Check actual actions and outcomes in the affected systems.
Is a fixed monthly price guaranteed?
No. It depends on the contract, included usage and effective controls. Clarify overages and stopping behaviour.
