From Business Problem to Technical Spec

“We need an AI agent” is a technology preference, not a requirement. A usable specification begins with a business situation: who is trying to accomplish what, what happens today, where the process fails, and what evidence would show an improvement.

Requirements gathering is translation, not transcription. Non-technical stakeholders know the work, exceptions, relationships, and consequences. Technical teams know system constraints and failure modes. The job is to build a shared model precise enough to test without forcing every participant to speak the same jargon.

Start with the work as it exists

Interview the people who perform, supervise, and receive the output of the workflow. Ask them to walk through a recent real example rather than describe an ideal average day.

Useful questions include:

What event starts the work, and how is it noticed?
Which systems, messages, and documents are used?
What decision is made, by whom, and with which information?
Which cases are easy, ambiguous, sensitive, or prohibited?
What happens when data is missing or a system is unavailable?
Who owns the next action, and how do they know it is theirs?
What is the cost of delay, error, and unnecessary escalation?
What must never happen?

Speak in the stakeholder's vocabulary and repeat the workflow back as a sequence. Ask for examples that contradict the first explanation. The exception often reveals the real requirement.

Observe the process when possible. A policy may say every quote receives follow-up in two days, while actual work depends on one person's spreadsheet and memory. Both facts matter to the design.

Translate needs into a workflow specification

Write a short problem statement without naming a solution. Identify the user groups, desired outcome, current baseline, scope, exclusions, and constraints. Then describe the proposed workflow:

Trigger: the event and eligibility rules.
Inputs: required data, source, freshness, permission, and quality.
Decision: deterministic rules, model role, confidence handling, and prohibited decisions.
Actions: systems changed, messages sent, and approvals required.
Exceptions: retry, fallback, human review, and escalation.
Evidence: audit events, outcome measures, and acceptance tests.
Ownership: who operates, approves, supports, and changes it.

Define interfaces and non-functional requirements: latency, volume, availability, tenant isolation, retention, accessibility, security, regional constraints, and budget. “Fast” is not testable; “95% of eligible requests complete within two minutes during supported hours” is.

For generative behavior, use a representative evaluation set. Define required facts, allowable variation, abstention behavior, citations, and unsafe outcomes. A few polished demo prompts are not an acceptance test.

Separate rules from model judgment

Use deterministic code for hard constraints such as tenant authorization, spending limits, required approvals, suppression lists, and eligibility. Use a model where interpretation or generation adds value, with a safe path for uncertainty.

Document what context the model receives, which tools it may invoke, and what requires human confirmation. Describe the consequence of a false positive and false negative. A low-confidence classification that creates a review task is different from one that automatically emails a customer.

This boundary helps stakeholders make informed tradeoffs rather than debating an abstract “accuracy” number.

Manage expectations with staged commitments

Separate assumptions, decisions, dependencies, risks, and open questions. Assign an owner and review date to each. Show a thin end-to-end prototype early using representative but safe data, then validate one workflow before expanding scope.

Agree on a baseline before implementation. Set a pilot threshold, not a guaranteed business outcome: for example, a workflow must correctly route a defined percentage of labeled test cases and never cross a tenant boundary. Business impact still depends on volume, staff adoption, seasonality, and follow-through.

Carry that baseline into the adoption and ROI measurement plan.

Use a decision log when scope or constraints change. Explain effects on timeline, cost, quality, and risk. “Yes” without the tradeoff is not expectation management.

Common failure modes

Beginning with a chosen model or vendor before understanding the workflow.
Interviewing executives but not the people who perform the work.
Designing for the happy path and discovering exceptions in production.
Writing vague requirements such as “accurate,” “secure,” or “real time.”
Letting a model enforce authorization or other hard business constraints.
Promising ROI before measuring the baseline and adoption conditions.
Allowing new requests into a pilot without recording their impact.

Implementation checklist

Observe and map a recent real workflow from trigger to outcome.
Interview operators, owners, recipients, security, and support stakeholders.
Write the problem, baseline, users, scope, exclusions, and constraints.
Specify inputs, decisions, actions, exceptions, evidence, and ownership.
Convert qualitative expectations into measurable acceptance criteria.
Build a representative evaluation set including edge and prohibited cases.
Define human approval, fallback, and stop conditions.
Record assumptions, risks, dependencies, and scope decisions.
Obtain stakeholder acceptance of the workflow and operating model.

Measurable signals

Track unanswered discovery questions, requirement changes after build begins, acceptance-test coverage, exception cases represented, stakeholder review turnaround, pilot adoption, human override and escalation rates, workflow completion time, and the agreed business baseline. A useful discovery process reduces expensive surprises; it does not eliminate learning.