Context and task design
Define the trigger, required information and allowed outcomes. Give the agent a clear way to recognise that the request is incomplete or outside its remit.
Build agents that understand context, use approved tools and ask for help when the next action needs a person.
Discuss an agent workflowThe starting question
Begin with one task and a limited set of tools. Reading a customer record, drafting a reply and changing a commercial commitment have different consequences. We make those differences explicit in permissions, approval paths and the record of what happened.
An agent specification, tool contracts, an approval model, scenario tests, action logging and an operating guide.
The work / From design to operation
Define the trigger, required information and allowed outcomes. Give the agent a clear way to recognise that the request is incomplete or outside its remit.
Connect only the systems and actions needed for the task. Validate parameters and permissions on the server, independently of what the model proposes.
Draft first where consequences matter. Route uncertainty to the right colleague with enough context to decide, rather than asking someone to review a raw model transcript.
Test ordinary cases, misleading input, changed permissions and failed tools. Record attempted and completed actions so an operator can investigate the workflow.
Designed into the system
Limited tools and scoped credentials
Independent action validation
Human approval for material commitments
Safe retries and duplicate prevention
No. Stable rules are usually better expressed as ordinary software. An agent is most useful where the workflow genuinely needs interpretation or contextual decisions within a defined boundary.
Subject to approved APIs, account access and channel requirements. The integration must handle consent where relevant, message state, failures and escalation to a person.