Start agent design with the business constraint

Understand the decision

Imagine a service team asks for an agent to triage incoming cases. “Triage” could mean making a recommendation to an operator, assigning a case to a queue, or changing its priority. Ask who owns that decision today and what evidence they use.

Review a handful of real cases with the people doing the work. Include one routine case and one they would escalate. Ask them to walk through where they look for information and when they hand the case to someone else.

Capture the constraints

Three questions will usually uncover decisions that affect the architecture:

1. Which action would cause the most rework or harm if the agent got it wrong?
2. Which information can the system read, and under whose identity?
3. When should the system hand back the case, and what does the operator need at that point?

Translate each answer into an observable requirement. “Keep a human in the loop” could become “A supervisor must approve any priority downgrade before the ticketing system is updated.”

Choose the first workflow

Start with one case type the team handles often enough to evaluate. Measure review time and how often the operator changes the recommendation. Capture a reason for each override. Those reasons help you tell whether you need better evidence, a clearer policy, or a different workflow.

Write down what the team considers an acceptable outcome for a real case. Use that example in the prototype review and the first evaluation set.