An AI agent is software that uses a model to help choose steps towards a goal, often by requesting tools or information. Implementations vary in autonomy: some stay inside a tightly defined workflow, while others select a sequence of actions within a broader boundary.
The model does not become the business system’s authority. The surrounding application must decide which requests are valid, which actions are permitted and when a person needs to intervene.
Follow a single task
Consider an illustrative service request. The application identifies the customer, retrieves the relevant record and asks a model to propose how the request should be handled. It checks the proposal against the allowed fields and actions, then sends consequential changes for human approval where required.
If the request is ambiguous, the workflow asks for clarification. If a tool fails, the application records the failure rather than letting the model claim completion. If an external write has an uncertain outcome, it reconciles that system’s state before retrying.
This is the difference between a model’s proposed next step and a verified business result. Both need to be visible in the design.
Know when an agent is useful
Model-directed work is a candidate when the next step depends on interpreting varied information that fixed rules do not handle well. Document triage, knowledge-assisted preparation and bounded investigation can fit this pattern.
Predictable tasks may be better served by ordinary software or automation. Sending a reminder after a confirmed appointment does not inherently require an agent to plan the work. Additional autonomy creates additional behaviour to test.
For each candidate, define the allowed inputs, tools, outputs and stopping conditions. Include the cases where the system should request help or decline to act.
Understand the AI harness
The AI harness is the surrounding runtime and controls that make model use part of a working application. It can manage context, task state, tools, permissions, verification and operating evidence.
Its responsibilities depend on the task. A read-only knowledge tool needs a different boundary from a workflow that proposes changes to financial records. Several agents or sub-agents are optional design choices, not prerequisites for a harness.
Keep credentials outside model context. Validate requests in software, authorise access at the appropriate boundary and limit the actions exposed by each tool.
Keep interpretation separate from calculation
A model may interpret a document and suggest a classification. Exact calculations should use an appropriate tested calculation path, with source inputs preserved for review.
Structured outputs help parse a proposal, but a correctly formatted result can still be substantively wrong. Test the values, source references and business constraints as separate acceptance conditions.
A confidence score supplied by the model is not sufficient authority to execute a sensitive action. Any score used for routing needs validation on the target task and must sit alongside the permission and approval rules.
Test behaviour, including the unwanted paths
Evaluate complete runs rather than only final answers. Include malicious document instructions, unavailable tools, duplicate events, incomplete information and attempts to exceed the user’s access.
OWASP’s excessive-agency guidance describes why excessive functionality and permissions can turn model errors into consequential actions. Restricting tools and maintaining application-side checks helps bound that risk.
Record observable actions and outcomes under suitable access and retention controls. A generated explanation does not reveal every internal cause of the model’s decision.
Start with a bounded role
Agree the process owner, reviewer and support responsibilities. Set limits on time, attempts and resource use. Show unfinished or uncertain work honestly to users.
The phrase “AI employee” can help describe a recurring software role, but it should not imply independent human judgement or unbounded authority. The AI Agents and Employees service focuses on those defined tasks, integrations and controls.
Deploying an agent is a software and operating decision. Its value needs evidence from the task it is meant to perform, along with a clear account of what it is not allowed to do.
Written by Anshul Kaushik, Managing Director at Ryzolv.
Back to Insights