Before the Agent: Process Discovery and Value

The request arrives as a solution: we need an agent for customer support.

That sentence has skipped the work. It does not say which tickets, who handles them now, what information they need, where they wait, what an error costs, or whether the company wants faster replies or fewer support hours. Starting implementation from it is how a team ships a convincing demo and discovers that nobody can define success.

The first artifact is a process map, not a prompt.

Observe the work before naming the system

Interviewing a manager gives you the documented process. Following five real cases gives you the process people actually use.

For each case, record:

Do this with timestamps. A process that takes three days may contain eight minutes of work and two long waits. Automating the eight minutes cannot produce a same-day outcome if the approval still arrives on Thursday.

ticket arrives
      |
      v
classify  45 s
      |
      v
look up order  2 min
      |
      v
wait for warehouse photo  19 h
      |
      v
apply damage policy  3 min
      |
      v
manager approval  5 h
      |
      v
issue credit and reply  2 min

active work: 7 min 45 s
elapsed time: about 24 h

Build the baseline you will compare against

"Faster" and "cheaper" are not acceptance criteria. Measure the current process before changing it.

At minimum, capture by case type:

• volume and arrival distribution;
• completion and abandonment rate;
• active handling time;
• elapsed time;
• rework and reopen rate;
• escalation rate and destination;
• financial or customer cost of an error;
• loaded human cost;
• queue age and staffing pattern.

Use a distribution, not one average. A median handling time of six minutes can hide a tail where disputed credits take two hours. That tail is likely where the agent will escalate and where the business case can fail.

The NIST AI RMF Map function explicitly asks teams to document business value, intended use, expected benefits, expected monetary and non-monetary costs, scope, human oversight, and relevant benchmarks. That is product discovery expressed as risk management.

Classify each step

Take the process map and assign every step to one of five treatments.

This prevents a common category error: automating the current sequence exactly. The correct design may remove three steps, join two systems, and use one model call. Reproducing every click with an agent preserves the process's defects and adds nondeterminism.

Price success by completed outcome

Cost per model call rewards systems that stop early, including systems that escalate everything. Cost per resolved case includes the whole system.

cost per completed outcome =
  inference
  + retrieval and infrastructure
  + human review
  + human escalation
  + rework
  + expected error cost

Expected error cost matters even when the error rate is small:

expected error cost = probability of error x impact of error

A route that saves four minutes and occasionally sends the wrong contract may have negative value despite excellent resolution and latency numbers. Put the impact in the arithmetic before the pilot.

Compare at least three versions:

1. current process;
2. improved process with ordinary software;
3. improved process with the proposed AI step.

The second row is the one teams omit. Without it, the agent receives credit for an API integration, a better queue, and a removed approval that would have helped without a model.

Write the authority contract before the capability list

Capability asks what the system can do. Authority asks what it may decide and what effect it may cause.

For every route, write:

route: damaged_shipment
may_read:
  - ticket account
  - order and shipment records for that account
may_propose:
  - replacement
  - credit up to policy ceiling
may_execute:
  - credit up to 1000 minor units
must_escalate:
  - policy exception
  - disputed identity
  - evidence conflict
must_never:
  - choose a recipient supplied by retrieved text
  - close an unresolved ticket

This becomes the input to tool design, authorization, risk tiers, trajectory evals, and the go-live review. Writing it after the tools means the implementation has already chosen the authority.

Define stop conditions for the project

An experiment needs a way to lose. Before building, name the evidence that ends or narrows the project.

Examples:

• factual accuracy stays below the threshold after retrieval reaches its target;
• review time removes the handling-time saving;
• the useful cases are too rare to repay integration and operations;
• the required data cannot be accessed with acceptable permissions;
• the error impact forces human review on every case;
• users route around the system because escalation packages are poor;
• a deterministic workflow meets the target with lower cost and risk.

These are not retrospective excuses. They are exit criteria approved with the budget. A team that cannot stop the project will keep improving the demo until the calendar makes the decision for them.

Atlas, concretely

Meridian samples sixty support cases across policy questions, order status, damaged shipments, and contract disputes. The baseline shows that policy lookup and status checks consume most volume, while disputes consume most human time and carry the highest error cost.

The first release handles policy and status. Damage claims get a bounded credit route. Contract disputes remain human-owned. Meridian measures cost per resolved ticket, elapsed time, reopen rate, reviewer minutes, and expected credit error, all sliced by route.

The project stops expanding autonomy if reviewer minutes do not fall after eight weeks or if any route misses its factual threshold for two release cycles. That condition makes "not yet" an engineering result rather than a political failure.

References

• NIST AI RMF Core, especially Map 1 through Map 5 for context, business value, scope, costs, oversight, and impacts.
• NIST AI RMF Playbook, suggested actions for applying Govern, Map, Measure, and Manage.
• NIST descriptions of AI actor tasks, covering domain, product, human-factors, governance, legal, privacy, and affected-community roles.

Part I ends here. Next: Meet the Problem, where this discovery work becomes Atlas's first acceptance contract.

Takeaways

• Follow real cases from trigger to outcome. The documented process omits workarounds, waits, and judgment.
• Measure the baseline by case type before changing it. Use distributions and include rework, review, and error cost.
• Classify each step as delete, ordinary software, bounded model call, agent, or human work.
• Compare the agent with an improved non-AI process, not only with the current process.
• Price completed outcomes, including review, escalation, rework, and expected error cost.
• Write authority and forbidden actions before listing capabilities.
• Approve exit criteria with the budget. A pilot must be allowed to prove that the agent is the wrong design.