Answer, ask, act or wait
The hardest product decision in an enterprise AI agent is not the model. It is the rule for when the agent answers, when it asks, when it acts and when it waits for approval.
The problem
An employee types a request into Microsoft Teams: “I need access to the finance dashboard.”
An AI agent can respond in four ways. It can answer with the access policy. It can ask which dashboard the employee means. It can grant the access. It can send the request to a manager for approval and wait.
Each response is right in some situations and wrong in others. An agent that only answers is a search box. An agent that asks too often is slower than a form. An agent that acts without care will eventually do something that a person has to undo. An agent that always waits for approval has automated nothing.
Most discussions about agents focus on the model and the tools. In my experience, this four-way choice decides whether employees trust the agent and whether the business case holds.
What I built
I lead product for an AI platform at Rezolve.ai. More than 300,000 employees use it inside Microsoft Teams, Slack, voice and web. They use it for IT and HR requests such as access, provisioning and incident triage.
I cannot show the product here. I can describe the behaviour model, because the model is the idea.
We defined how the agent behaves at each step of a request. The agent chooses one of four moves.
Answer. The agent answers when the request is a question and the answer exists in enterprise knowledge. The answer is grounded in that knowledge. The agent does not answer from general knowledge about how companies usually work.
Ask. The agent asks a clarifying question when the request can mean more than one thing. A good clarifying question offers the likely options, so the employee can reply with one word.
Act. The agent completes the request when the intent is clear and the action is safe to take. Access requests, provisioning and many HR requests fall into this group.
Wait. The agent requests approval first when the action carries risk or when policy requires a human decision. The approver sees what will happen and can approve in one step.
What I learned
The four moves need different measures of quality. A wrong answer and a wrong action are different failures. We judge AI features before release with LLM-as-a-judge scoring and human-labeled regression sets. We sort every failure into one of four causes: retrieval, model, tool or UX. A team that knows the cause knows who should fix it.
Autonomy comes from the guardrails. Customers allow an agent to act because approvals, role-based access, audit logging and PII redaction exist. These controls are often described as limits on the agent. I see them as the reason the agent is allowed to do anything.
The outcome is the proof. The platform resolves about 60% of L1 requests autonomously. Support volume dropped by 35%, and cost fell by 25%. Service desks save about 1,800 agent-hours each month. An agent that could only answer questions would not produce these numbers. The completed actions produce them.
The boundaries move. A new customer starts with more approvals. The boundary between acting and waiting shifts as the audit trail builds confidence. The product has to make that shift easy for an administrator to make.
What this means for product teams
- Write the behaviour rules before you choose the model. Decide when your agent answers, asks, acts and waits. Write the rules down as a product spec. The model can change later. The rules are the product.
- Build evals for each move. Test grounded answers, clarifying questions, completed actions and approval requests separately. One overall accuracy number hides the failures that matter.
- Treat approvals as a feature. A fast, clear approval step is what lets customers hand real actions to the agent.
- Measure completed work. Count the requests that were resolved without a person, and the hours that this saved. Conversations and message counts do not show value.