The Production Failure That Defines the Problem
The typical enterprise agentic AI pilot failure has a specific structure. A team identifies a process that seems automatable. They select an AI model and give it tools: access to a database, an API, a scheduling system. They write a broad prompt describing the goal. They test it in development, where inputs are clean and edge cases are rare. It works. They deploy it to production, where inputs are messy and edge cases are constant. It fails, sometimes loudly, sometimes silently.
Miles K.’s February 2026 analysis names the structural reason: “Without a problem-first approach, you are not building an agent; you are creating a stochastic loop that lacks a defined exit condition.” He identifies three costs of adding autonomy that architects tend to underestimate: latency (every reasoning step adds response time), reliability (errors compound across probabilistic steps) and tokens (intermediate reasoning and retries drive up API spend). In an enterprise setting, two more costs follow from the same root cause. The more autonomous the agent, the harder it is to reconstruct what it did and why. And with no defined scope, there is no definable authorization boundary.
For enterprises in regulated industries such as financial services, healthcare and government, this failure mode can cost more than a failed pilot. If the use case falls into a high-risk category under the EU AI Act, an agent without a defined scope and a documented authorization model gives you nothing to build the Article 9 risk management system on.
Why the Problem-First Approach Changes the Architecture
Starting with the problem is not just a planning preference. It is the decision that determines the agent’s scope, authorization model, confidence threshold, escalation design and integration requirements, all before a line of code is written or a model is selected.
Consider two hypothetical teams building claims processing automation for the same insurer. Team A starts with a model: they choose a capable LLM, give it access to the claims database, and prompt it to “process incoming claims efficiently.” Team B starts with the problem: they define that 2,400 claims per week require manual triage, that 70% of those follow patterns that can be classified reliably, and that the remaining 30% require human review because they involve disputed coverage, incomplete documentation or claim values above €50,000.
Team B’s problem definition immediately produces a scoped agent task (classify the 70% that follow a reliable pattern), a confidence threshold (route anything below 85% confidence to human review), a specific human escalation trigger (value above €50,000, always), an audit trail requirement (every classification decision logged with the data accessed), and a human oversight design that is structural rather than advisory, which is what EU AI Act Article 14 asks of high-risk systems.
Team A’s model-first approach produces an agent with a broad goal and no governance design. Team B’s problem-first approach produces an agent that is scoped and governed before the first prompt is written. The difference in production outcomes is not a consequence of model quality. It is a consequence of how the problem was defined.
The Five Questions: A Problem-First Framework for Enterprise Agentic AI
The following five questions, answered with specificity before any agent is designed, produce the minimum viable problem definition for a governed enterprise AI agent. The framework is designed for operations and IT leaders, not developers. It assumes that the technical implementation will follow once these questions are answered, not precede them.
| Question | What a good answer looks like | Why it matters for agent design |
|---|---|---|
| 1. What specific process fails, and how does the failure manifest? | A named workflow step, a measurable outcome gap, a specific friction point. Not “we want to automate” but “claims triage takes 14 days because classifiers manually review 2,400 submissions per week.” | Defines the agent’s task precisely. Without this, the agent’s scope cannot be bounded, and unbounded scope is a common cause of production failures. |
| 2. What constraints govern the solution? (compliance, data, human, time) | Named regulatory frameworks (GDPR Art. 30, DORA, EU AI Act Art. 14), data residency requirements, mandatory human review steps, SLA windows. Constraints are not obstacles; they are design inputs. | Constraints define what the agent cannot do. For high-risk AI, EU AI Act Art. 9 requires risk management across the system’s whole lifecycle, and the problem definition is where it starts. |
| 3. What does a successful outcome look like, and how will you measure it? | A specific metric with a baseline: “14-day average processing time reduced to under 4 days” or “2,400 manual reviews per week reduced by 70% while maintaining <0.5% error rate.” | Without a success metric defined before deployment, the agent’s confidence threshold cannot be calibrated, and you cannot know whether the agent is performing or slowly degrading. |
| 4. Where does human judgment remain essential? | Specific decision points: claims above €50,000, eligibility determinations where the applicant disputes the decision, cases involving incomplete data. Not “humans review everything” but a specific threshold. | This question produces the human-in-the-loop design. For high-risk AI, EU AI Act Art. 14 requires effective human oversight. The answer to this question is the governance design, not a policy statement. |
| 5. What existing systems does the solution need to integrate, and what needs to be true about them? | Named systems with integration method: “SAP S/4HANA via OData for order data; legacy fleet system via SOAP for dispatch records.” Data quality requirements. API availability. Real-time vs. batch. | An agent operating on incomplete data produces confident wrong answers. The integration architecture is not a technical detail to resolve after the agent is designed. It is a prerequisite for knowing whether the problem can be solved with an agent at all. |
Question 1: What Specifically Fails?
The first question is the hardest to answer precisely, and the most important to get right. “We want to automate our claims process” is not a problem definition. “Claims triage takes an average of 14 working days because two analysts manually review 2,400 incoming submissions per week, of which approximately 1,680 (70%) follow a recognizable pattern that can be classified reliably” is a problem definition.
The level of specificity matters because it determines the agent’s task scope. An agent scoped to classify the 70% of claims that follow a reliable pattern is a fundamentally different design from an agent scoped to “automate claims.” The first has a bounded input set, a measurable output and a clear handoff condition (the 30% it cannot classify). The second has no natural boundary and no exit condition: the stochastic loop.
The question also identifies what the agent is not responsible for. Defining what fails specifically is simultaneously defining what the agent should not attempt to do. That exclusion boundary is the agent’s scope definition, and scope definition is the primary risk control in a governed agentic AI architecture.
Question 2: What Constraints Govern the Solution?
In enterprise environments, constraints are not obstacles to work around after the design is complete. They are design inputs that shape what an acceptable solution looks like before any technology is selected. For European regulated enterprises, the most material constraints are:
- Regulatory compliance requirements: GDPR Article 30 requires a record of processing activities, and that record has to cover the processing an agent performs on personal data. For high-risk AI systems, EU AI Act Article 9 requires a risk management system that runs as a continuous, iterative process across the system’s lifecycle, and the problem definition is where that process starts. The answer to Question 2 is the first artifact of that work.
- Data residency and access constraints: Which systems the agent can access, under what authorization, and whether the data those systems hold can cross jurisdictional boundaries. DORA requires financial entities to identify, classify and document the ICT assets that support their business functions, which includes every system an automated workflow touches.
- Mandatory human review requirements: Certain decisions in regulated industries cannot be left to an AI system alone, regardless of confidence level. Identifying these before agent design means the human-in-the-loop architecture is built in from the start, not retrofitted when a regulator asks for it.
Constraints answered at Question 2 produce the governance design: the authorization model, the data access policy and the mandatory escalation architecture. For more on how compliance, governance and risk management interact in enterprise AI, the AI governance framework guide explains the three layers and their dependencies.
Question 3: What Does Success Look Like, and How Will You Measure It?
The answer to this question is not “the agent works.” It is a specific metric with a baseline, a target and a measurement method.
“Average claims triage time reduced from 14 working days to under 4 working days for the 70% of claims the agent handles, with a false classification rate below 0.5% of approved claims, measured against the 6-month pre-deployment baseline” is a success definition. It specifies what the agent is responsible for (the 70%), what it is not responsible for (the 30% escalated to human review), and the quality constraint that must hold (0.5% false classification rate).
This definition does more than set evaluation criteria. It calibrates the agent’s confidence threshold. If the acceptable false classification rate is 0.5%, the confidence threshold must be set high enough that claims below it are routed to human review, not processed by the agent. The success metric and the confidence threshold are two expressions of the same requirement. Defining success first means the governance design is derived from business requirements, not from technical defaults.
Question 4: Where Does Human Judgment Remain Essential?
This question produces the human-in-the-loop design: the specific decision points, thresholds and trigger conditions under which the agent escalates to a human reviewer rather than acting.
The answer is not “humans review everything” (which defeats the purpose of the agent) or “the agent handles everything” (which is ungovernable). It is a specific set of conditions: claim value above a defined threshold, applicant disputes the automated decision, input data is incomplete, or confidence score falls below the calibrated threshold. Each condition is a named escalation trigger.
For high-risk AI systems, EU AI Act Article 14 requires that the system be designed so natural persons can effectively oversee it while it is in use. Oversight has to exist in the system, not only in a policy document, and the answer to Question 4 is that design. If this question is answered after deployment, the human oversight mechanism is a retrofit. If it is answered before, it is architectural.
The timeline moved; the requirement did not. Under the Digital Omnibus on AI (Regulation (EU) 2026/1744), obligations for stand-alone high-risk systems listed in Annex III apply from December 2, 2027, and for high-risk AI built into products covered by Annex I from August 2, 2028. An agent designed today for a high-risk use case will be in production when those dates arrive. Our EU AI Act guide for operations teams sets out what applies when.
Question 5: What Systems Does It Need to Integrate, and What Needs to Be True About Them?
An agentic AI application does not operate in isolation. It queries systems, writes to systems, triggers downstream workflows, and depends on the data quality and availability of the systems it connects to. Defining the integration architecture before the agent is designed is the difference between an agent that has the context to act reliably and one that produces confident wrong answers because it is operating on incomplete data.
The question has two parts. The first is naming the systems: which ERP, which workflow engine, which customer database, which external registry. The second is stating what must be true about them: which fields the agent will read, what data quality is required for a reliable classification, whether real-time or batch data is needed, and which APIs are available versus which require custom integration work.
In practice, answering Question 5 often reveals that the technical prerequisites for the agent are not yet in place: the relevant data sits in three separate systems that do not share a common key, or the API the agent needs is not available without a new integration project. Discovering this at Question 5, before the agent is built, is a planning problem. Discovering it in production is a failure.