Tool-Using Agents
Our agent layer can give model-driven systems controlled access to tools required to retrieve information, perform calculations, interact with company software, or execute bounded work.
What a tool can be
Tools can include APIs, databases, search, internal software, calculators, document systems, and deterministic services.
The agent is not granted unrestricted computer access simply because it can reason about a task.
Tool contract
A production tool should expose a bounded interface with defined inputs, outputs, permissions, validation, and failure behavior.
- Agent decision
- Tool selection
- Schema-validated arguments
- Authorization
- Execution
- Result validation
- State / evidence returned
Tool schemas reduce ambiguity between natural-language reasoning and deterministic execution. For consequential writes, the execution boundary can also enforce idempotency, approval requirements, business rules, or transaction state independently of the model.
Read versus write
The risk surface changes materially when an agent moves from reading to modifying state. Reading a customer record and updating a customer record are not equivalent capabilities. We can therefore scope permissions by:
- System
- Action
- Data type
- Customer
- Business unit
- Role
A reasoning agent can have broad analytical visibility while still being unable to perform consequential writes.
Validation
Tool execution is logged and validated rather than trusted because the model selected it. Validation can occur before execution, after execution, or both. Exact constraints should remain deterministic where possible.
The agent can decide which bounded capability is useful without becoming the authority that defines whether every proposed action is allowed.
Models reason. Tools act. Policies control what action is permitted.
Tool selection is part of the workload
An agent should not have to choose among every tool available across the company. The accessible tool set can be narrowed by task, role, or execution state. A customer-analysis workload may receive read-only access to customer systems and search while a financial workflow receives different tools and stricter validation. This reduces accidental capability and makes tool-use evaluation more meaningful.
A tool call is also not treated as evidence merely because it executed successfully. The returned data can still require source checks, schema validation, or comparison with existing state.
The useful abstraction is therefore bounded capability, not unrestricted agency: the model can reason over a controlled set of actions whose permissions and side effects are enforced outside the model.