An agent needs a job, not a personality.
Start with a responsibility, a boundary, and a way to tell whether the work was done well.
Define an AI agent by the job it is responsible for, the information it may use and the actions it may take. Evaluate real examples—including cases where it should stop—before expanding its permissions.
The interesting question comes after the demo
A system that can hold a conversation is easy to imagine using everywhere. It can summarize, suggest, explain and draft. But broad capability does not tell a team when to trust it or where it belongs.
The useful question is more specific: what responsibility should this system take on? ‘Help operations’ is too broad to evaluate. ‘Assemble the context for a delayed order and draft a response for review’ gives the system a job, and gives people a way to judge its work.
Separate knowing from doing
An agent may need to find information, interpret it, and take an action. Those are different responsibilities with different consequences.
A support assistant might read order history and retrieve an approved policy. It might then propose a response. Issuing a refund is a separate step. Treating all three as one permission makes it harder to understand the risk and harder to design a useful review.
Begin by listing what the system can read, what it can suggest, and what it can change. Make the boundaries concrete enough that an operator can explain them to a colleague.
Decision guide
Three responsibilities, three boundaries
| Consideration | Responsibility | Review question |
|---|---|---|
| Read | Retrieve permitted records and approved policy. | Is this user allowed to see the source? |
| Suggest | Draft a next action with supporting context. | Is the proposal grounded and complete? |
| Act | Change a record through an approved operation. | Is the action allowed, and does it require confirmation? |
Start with a responsibility, a boundary, and a way to tell whether the work was done well.
Give it a source of truth
An answer that sounds reasonable is not the same as an answer grounded in the business. Decide which sources the application should use and what happens when those sources disagree.
Show the supporting context alongside an important suggestion. Make missing information visible. A system should be able to stop and ask for a review rather than fill a gap with a confident guess.
This changes the interface too. The most useful result may not be a chat bubble. It may be a proposed action beside the order, the relevant history, and a clear approval control.
Evaluate the job with real examples
Collect examples from the people who currently do the task. Include routine cases, ambiguous requests and situations where taking no action is the correct choice.
Agree on what a good result means before broadening the system’s permissions. Look at correctness, the context supplied for review, and whether the proposed next step is allowed. Keep a record of failures so the team can improve the workflow instead of repeatedly correcting the same problem.
A useful first deployment has a narrow responsibility and a practical way for people to intervene. Its scope can grow as the evidence supports it.
Sequence of work
Evaluate the job before widening it
- Collect examples
Include ordinary tasks, ambiguity and denied actions.
- Define outcomes
Specify what correct completion or refusal looks like.
- Inspect results
Check application state as well as the answer.
- Expand deliberately
Increase scope only when evidence supports it.
Make the human role intentional
Human review should have a purpose. Asking someone to approve everything without enough context can become another repetitive task. Asking for judgment at the point where it matters can make the entire workflow more dependable.
The aim is useful work with understandable boundaries. Give the agent a job your team recognizes, and give the team a clear view of what it did.
Put this into practice
For a concrete product example, see how TWIMCO built Spin:Market, including AI agents and natural-language control. The AI applications and agents service describes how we approach this work. Anthropic’s Building effective agents is a useful reference for distinguishing fixed workflows from agent-directed execution.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.