Gartner has predicted that over 40% of agentic AI projects will be cancelled by the end of 2027 (Gartner, June 2025). The prediction is specific to agentic AI, systems designed to take autonomous actions inside business workflows. It points to a consistent structural cause: organizations deploy first, then discover that the workflow was not ready for automation.
This pattern is visible across logistics, banking, insurance, and supply chain operations. The project starts with a vendor demo, moves to integration, and stalls when the agent meets edge cases nobody mapped. Months of tuning follow. Then the project gets scoped down, or shelved. The demo never failed. The workflow was never ready.
What the deploy-first pattern looks like in practice
Consider a mid-market logistics company that handles 12,000 shipment exceptions per week across three consolidation centers. Each exception, whether a missed scan, a weight discrepancy or a routing conflict, gets flagged in the TMS and routed to a dispatch desk where analysts pull data from the WMS, the carrier portal, and email threads, then decide whether to reroute, hold, or escalate.
The operations VP commissions an AI agent to handle these exceptions automatically. The vendor connects the agent to the TMS and WMS APIs, configures a set of decision rules, and switches it on in a pilot lane. Within two weeks the agent is escalating 60% of cases to human reviewers because the TMS status codes do not map cleanly to the WMS exception categories. The analysts are now doing their original job plus reviewing the agent's recommendations. Processing time per exception has increased, and the pilot is labeled a learning phase.
Four months later the project is still in pilot. The scope has been reduced to a single exception type, weight discrepancies on a specific lane, and the agent handles roughly 200 of the 12,000 weekly exceptions. The ROI case that justified the project no longer applies.
The failure was in the first step. No one observed the actual workflow before automating it. No one counted how many exception types existed, how often each one occurred, or how many of them followed a pattern an agent could handle consistently. The TMS-to-WMS mapping gap would have surfaced in a 2-day diagnostic workshop.
What diagnosis answers
Proxima's diagnostic phase runs before any agent takes action. It is structured around three questions:
- Where is the actual bottleneck? Queue times, rework rates, and escalation frequency, all measured from live operations data gathered during a 2-day diagnostic workshop using sample records.
- Is it automatable? Some bottlenecks are people problems or process problems. Applying an agent to them accelerates the dysfunction and makes it more expensive to undo. The diagnostic separates automatable steps from organizational ones.
- What would the agent need to do? Define the decision space before building anything: what inputs the agent sees, what decisions it makes, what approval rules apply, and what happens when it gets it wrong.
The output of this phase is a Proxima Diagnostic Report. It contains a constraint map of the workflow and an automation fit score for each step. This is the document the logistics company should have had before connecting a single API.
The phased structure: understand the work, then suggest without acting
Proxima's process is built around phase gates with explicit criteria. If the criteria are met, the engagement moves forward. If they are not, it does not proceed.
Phase 0: Diagnostic (2 days). A structured workshop using the customer's sample data. The Diagnostic Runner analyzes 500+ records, classifies exception types, simulates agent decisions against actual outcomes, and produces a business case with specific accuracy numbers. Output: the Diagnostic Deck with constraint map and automation fit score.
Phase 1: Understand the work (Observe, 1-2 weeks). The engineering team maps the actual process in production, validates review findings against live data, and confirms the automation scope. No actions are taken.
Phase 2: Suggest, don't act (Shadow mode, 1-2 weeks). The system suggests what to do but does not take action. People continue to make every decision while Proxima compares its suggestions with their choices and measures accuracy, consistency and edge-case handling. Before testing starts, the customer and Proxima agree the quality gate for each action category. If the evidence does not clear that gate, the category does not move into supervised automation.
These phase gates are binding. The logistics company described above would have discovered the TMS-WMS mapping gap during Observe. The 60% escalation rate would have been visible in Shadow, and the project would not have moved to supervised automation. The diagnostic would have taken 2-4 weeks instead of the four months the pilot consumed.
What skipping diagnosis costs
The downstream costs of skipping diagnosis are specific and measurable:
- Scope creep from unmapped edge cases. Without a constraint map, the team discovers exceptions in production. Each one expands the project scope and extends timelines.
- Stakeholder trust erosion. Decision-makers who approved the budget see the agent struggle with basic cases. Rebuilding confidence in the automation program takes longer than the original deployment.
- Sunk cost escalation. Once integrations are built and the agent is configured, the project accumulates enough engineering hours that abandoning it feels irresponsible. The organization keeps spending on a system that was never validated against the actual workflow.
In BFSI operations the pattern repeats in loan processing, claims triage, and KYC review. A bank deploys an agent to auto-approve standard loan applications. The agent works on clean applications but flags 45% of cases for human review because the income verification step pulls data from three systems with inconsistent formatting. Analysts now review agent recommendations in addition to handling the cases the agent rejected. Total throughput drops. The project is recast as an augmentation tool to justify the spend, even though the original business case depended on straight-through processing.
A diagnostic workshop would have mapped the income verification bottleneck, measured the data inconsistency rate, and determined that the agent needed a normalization layer before it could make approval decisions. That finding would have changed the project scope, the timeline, and the ROI model before any code was written.
Running a diagnostic before you commit
Whether you use Proxima or run this internally, the steps are the same:
- Map the workflow as it actually runs. Sit with the team. Trace the handoffs. Count the exceptions. Ignore the process document. Map what people actually do.
- Quantify the bottleneck. Measure time per incident, error rates, escalation frequency, and revenue exposed by delay or rework. Get numbers, not estimates.
- Run a shadow comparison. Have the agent generate recommendations alongside human decisions for 1-2 weeks. Score recommendation quality and business outcomes by action category. Agree the threshold before testing and hold to it.
- Set explicit autonomy boundaries. Define what the agent can do without approval, what requires human sign-off, and what triggers escalation. Write these down before the agent takes any action.
- Decide based on evidence. If the shadow comparison proves the agent is reliable within the defined boundaries, proceed to supervised automation. If it does not, stop. The diagnostic has done its job. It prevented a failed deployment.
Proxima structures this entire sequence into its phased model because enterprise operations teams need proof before granting more responsibility. The Observe and Shadow phases produce that proof. Next, a person reviews and approves each action (HITL). Only then can routine, proven actions run automatically within agreed limits (Autopilot). If the results do not support automation, the engagement does not continue.