Step one: find a viable process where customers are waiting

Asking business teams "what AI use cases do you have?" rarely yields good answers. Operators spend their days serving customers, maintaining relationships, and handling exceptions. Customers, meanwhile, don't proactively ask for AI next quarter. Asking frontline staff to pause their work and invent an AI roadmap from thin air is the wrong starting point.

A more reliable approach is to work backwards from the customer: identify where customers wait, complain, or churn, then examine the work, data, evidence, and ownership behind that experience. The original article breaks this examination into five lenses.

1. Customer interaction: Look for places that change customer outcomes. This could mean offering insights they didn't have before, compressing multi-day waits into minutes, or improving the product between releases. Ajzenstadt specifically notes that onboarding moments—account opening, document review, new-customer activation—are often undervalued; when customers can't use a service quickly, that's a signal to investigate further.
2. Underlying work: Break steps into categories: deterministic, judgment-intensive, exception-driven, and relationship-dependent. Machines should handle deterministic steps and prepare materials for judgment calls; humans remain responsible for decisions, approvals, and exceptions. If most of the work depends on complex judgment or client relationships, save it for a later pilot and choose processes where acceptance criteria are easier to define up front.
3. Context: Verify where facts live, who owns them, what fields actually mean, and what sensitivity levels apply. If no one internally can explain what the data means, defining the data is the first job.
4. Evidence: Check whether the company can currently measure work units, volume, cycle time, hands-on time, rework, exception rates, and unit costs. Without a current baseline, there's no way to prove what changed after the pilot.
5. Ownership: Pre-assign a process owner, data owner, and executive sponsor. If no one will take over running the process after the pilot, and no one is willing to make a go/no-go decision based on evidence, the process is not viable.

Companies should identify 3–5 candidate processes, rank them by value, feasibility, risk, and reuse potential, and then choose just one to start. Anything without real users, real data, a signable baseline, or clear ownership should be eliminated before development begins. Goals like "redesign the entire organization" that can't be validated in a short cycle also fail the test.

Once selected, walk through the process with the people who actually do the work. Collect representative cases, exceptions, permissions, and undocumented expert judgment. Interview first, then inventory technology; before reading code, ask who owns each dataset and what each field represents. Ajzenstadt also requires writing down a single business outcome and explicit non-goals, because teams easily expand a small pilot into a full system by week two.

Step two: agree on baseline and evaluation criteria before building the agent

The critical part of Ajzenstadt's ten-step method isn't the number ten; it's the ordering. If you pick metrics after seeing model outputs, you'll naturally favor whatever the model does well. If you build the baseline only after the pilot ends, you can't tell where changes came from. Baseline metrics, a golden set, and critical failure categories must exist before the agent does.

Both sides must agree on current workload, cycle times, hands-on processing time, quality and rework rates, exception rates, operating costs, and the measurement window. How things are done today, what performance level is being achieved, and how improvement will be calculated all need to be settled before the trial run.

The "golden set" here means a batch of real tasks whose results have been confirmed by the customer's own experts. Evaluation must also cover the failures the business cannot tolerate—wrong numbers, protected data leaks, or confident behavior when data is missing. Only when both successes and critical failures are baked into the criteria do trial results qualify for decision-making.

This preparation requires involvement from people inside the company. Under Limestone's "proof month" structure, executive sponsors dedicate 30 minutes a week and make decisions at checkpoints, process owners spend 2–4 hours weekly on walkthroughs and acceptance reviews, and data owners commit 1–3 hours at the start. A vendor can build the system, but business goals, field definitions, and correct answers must be confirmed by the company itself.

This also defines the budget boundary. Limestone reports its delivery mix as one embedded developer with an agent plus a part-time architect at US$15,000–20,000 per month; infrastructure for one operational agent project handling four groups of customer data runs about US$250 per month. These are different figures: the infrastructure bill doesn't include development, acceptance, or organizational handover costs. Their policy of no up-front diagnostic fees, monthly billing, and no payment if the first month doesn't satisfy is that vendor's commercial commitment—it can't substitute for the customer's own acceptance criteria.

Ajzenstadt adds one more discipline to the proof month: every activity must yield a decision, a tested hypothesis, a working increment, or a reusable asset. Anything that produces none of those isn't worth the team's time. This keeps walkthroughs, meetings, and development focused on actual results.

Step three: run a 2–4 week parallel trial and let evidence make the call

A pilot shouldn't start by making final decisions for people, nor should it write directly to systems of record. A safer minimal slice looks like this: the agent recommends, a named person decides, real data is used, the process runs in parallel with the old way, and every execution leaves a trace others can inspect.

These 2–4 weeks must answer three distinct questions at once: is it faster, is it better, and is it worth it once all costs are counted?

The article cites Faros AI's telemetry on 22,000 developers from 2026, noting that while task throughput rose 33.7%, defects per developer increased 54% and incidents per pull request rose 242.7%. Those numbers don't predict any single company's outcome, but they make it clear that speed and quality must be measured separately.

The pilot has four exits: continue, adjust, stop, or scale. If results don't clear the baseline agreed up front, stopping at four weeks preserves the budget for later. Adjustments should modify the implementation or the process approach, then be verified against pre-agreed criteria; lowering the bar when results disappoint isn't acceptable. If the scope of the task itself changes, the verification conditions need to be redefined—old and new results can't be treated as one comparison.

The figure places the trial run and all three measurement categories in the same phase: evidence accumulates continuously during execution, and the business and delivery teams together decide where the next investment goes.

After evidence supports expansion, harden production deployment and the operational handover

An agent that clears the pilot still needs reliable scheduling, observability, integration, failure fallbacks, cost ceilings, and continuous evaluation before it can operate daily. Every change requires re-evaluation, and nothing should depend on one engineer's laptop. The original article's seven-level adoption ladder describes the capabilities required to move from a personal tool to an organizational system.

Moving up the ladder doesn't mean basic permission management can wait. Ajzenstadt is explicit: knowledge structures need role-based access control from day one; data owners, sensitivity levels, and pilot leaders are identified before development starts. The extra hardening comes after a pilot passes—it's about production operations and scale, not about deferring data and permission boundaries.

Many companies are still at level 1 yet buying capabilities from level 7. The real bottleneck is usually level 4: moving scripts off personal computers and onto services that trigger reliably, log their activity, handle failures, and have clear ownership. Without stable hosted services, multi-agent handoffs can't become reliable daily operations either.

Governance also needs concrete retirement rules. Ajzenstadt suggests giving every agent a lifespan—enforce lifecycle management once tool count passes 100, retire anything that hasn't run in 90 days, and retire anything that falls below its evaluation threshold. These are management rules he proposes; the point is that someone must own decommissioning stale capabilities so obsolete agents don't keep valid credentials.

Finally, train the operators, hand over a runbook, and embed the capability into existing workflows. People's roles shift from starting tools one by one to accepting results, exercising judgment, and handling exceptions; every expert correction flows back into the golden set. Naming an owner is just the beginning—the operational handover is complete only when the team actually uses, evaluates, and maintains the capability.

Three cases show what the loop can do—and what it can't prove

Ajzenstadt offers three customer cases. They illustrate how the loop operates in practice but they can't by themselves prove the method will produce similar returns at every company: clients aren't named, and the original baselines, full evaluation sets, and third-party review materials haven't been published.

The article also admits plainly that no company transforms itself in one to three months. Software engineering has the deepest evidence because inputs, tests, and human gates are relatively well defined. Outside software and simple repetitive processes, there are no universally "obvious" use cases—every judgment- or relationship-intensive workflow has to establish its own baseline, golden set, and failure criteria from scratch.

These limitations don't weaken the loop; they explain its purpose. It doesn't promise answers in advance. It gives the company a controlled period to gather enough evidence to decide whether to keep investing.

The real compounding effect: the next process doesn't start from zero

The first process pays off in more than just possible savings. When the loop is run completely, the company keeps four kinds of assets that carry straight into the next pilot:

• Context layer: data definitions, owners, sensitivity levels, and cross-department boundaries are already mapped.
• Evaluation framework: the golden set, failure categories, routing logic, and quality gates can be extended.
• Hosted infrastructure: scheduling, logging, fallbacks, security review, and cost ceilings don't need to be rebuilt from nothing.
• Business ownership: runbooks, approval relationships, and owners are already embedded in daily operations; expert corrections keep flowing back into the golden set.

Models will change. Today's popular agent framework may be obsolete next quarter. But workflow knowledge, evaluation standards, hosting capabilities, and operational responsibility stay with the company. Because those assets persist, the second process starts from where the first one ended.

Find 3–5 candidate processes where customers are waiting, complaining, or churning, and use the five lenses to pick one. Define permissions, responsibility, baselines, and evaluation before development. Run a 2–4 week parallel trial on real data, and let throughput, quality, and economics jointly determine whether to continue, adjust, stop, or scale. Once the evidence supports expansion, refine production operations and handover, and carry the assets from each proven process into the next.