(This is Part 2 of a three-part series exploring what it takes to bring true agentic AI systems into enterprise production. In Part 1, we broke down the PoC-to-Production Engineering Gap, using the commercial aviation autopilot analogy to show why 88% of AI pilots stall and why true ROI requires rewriting the operating model rather than just layering AI on top of broken processes. In this Part 2 post, we look into the technical plumbing required to sustain these systems.)
The market for AI agents is expanding at an astronomical pace, projected to rocket from $7.6 billion in 2025 to $47.1 billion by 2030. Yet, inside the closed-door executive roundtable we hosted at the Chief AI Officer (CAIO) Summit in New York City, the mood surrounding this growth was remarkably grounded. As CAIOs and CTOs traded war stories, it became clear that while frontier models are becoming increasingly sophisticated, the underlying enterprise plumbing is severely cracking under the weight of autonomous execution.
When an individual user interacts with a standalone chat interface, a hallucination or a data error is a minor nuisance. But when you transition to autonomous software pipelines — where software agents make independent, multi-step decisions, call enterprise APIs and write back to core systems — the stakes change completely.
The technical baseline of the conversation quickly turned to a fundamental engineering paradox: How do we guarantee absolute safety and determinism in a software pipeline when the underlying engines powering it are fundamentally stochastic?
To solve that riddle, enterprise leaders have to completely re-engineer their approaches to data readiness, orchestration frameworks and system observability.
The False Dichotomy of Data Governance
We started the technical block of our roundtable by challenging the room on a classic friction point: What is your actual attitude toward foundational data governance and infrastructure cleanup before launching AI projects? Is a massive data cleanup a strict, non-negotiable prerequisite, or does heavy upfront governance slow things down and choke the very innovation you bought the AI for?
The room immediately split into two familiar camps. The traditionalists argued that building agents on top of un-governed data is a recipe for operational catastrophe. They aren’t wrong to worry. Gartner data shows that poor data quality costs organizations between $9.7 million and $15 million annually in operational inefficiencies and flawed decision-making. When autonomous agents act on that flawed data without human oversight, those financial damages compound severely and exponentially.
Because of this, Gartner predicts that organizations will abandon 60% of their AI projects through the end of 2026 due to insufficient data quality, while IDC forecasts a brutal 15% productivity loss by 2027 for companies that fail to prioritize data readiness.
On the other side of the room, however, the consensus was clear: If you wait until your entire enterprise data ecosystem is perfectly clean, your competitors will lap you three times over. Treating data readiness as a massive, multi-year monolith kills organizational momentum. Infrastructure and governance work is notoriously unattractive, feels like an immediate project showstopper and is incredibly difficult to secure executive buy-in for.
Our perspective at Growth Acceleration Partners — which mirrored the experiences of the highest-performing AI leaders in the room — is that the framing of “clean data first vs. move fast” is a completely false dichotomy. There is a highly practical way to work iteratively and in parallel to build momentum.
The trick is to realize that a read-only document summarization agent has vastly different data quality and security requirements than an autonomous transactional agent designed to write to a CRM or trigger a vendor payment.
We advise engineering teams to adopt a core heuristic: Govern the outputs, not just the inputs. You do not need to spend millions trying to boil the data lake ocean before writing your first line of agentic code. Instead, you must design modular, narrow solutions that hook into specific parts of your infrastructure as they become AI-ready. You don’t need perfect enterprise data, but you do need absolute data lineage for whatever specific asset the agent acts upon, and rigorous auditability for whatever actions that agent executes.
Deconstructing “AI-Ready Data”
To move past the marketing buzzwords, we pushed the executives to define what “AI-ready data” actually means inside their engineering organizations.
Gartner formally defines AI-ready data across four distinct pillars: data that is explicitly aligned to specific use cases, actively governed at the asset level, supported by automated pipelines with built-in quality gates and continuously quality-assured.
While that framework provides a solid theoretical baseline, the CTOs in our session noted that the real engineering failures happen in three practical dimensions that most enterprise teams consistently underinvest in:
┌──────────────────────────────┐
│ REAL-WORLD AI-READY DATA │
└──────────────┬───────────────┘
│
┌───────────────────────┼───────────────────────┐
▼ ▼ ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ RETRIEVABILITY │ │ TRUSTWORTHINESS │ │ PERMISSIONING │
│ Can the right │ │ Is the data │ │ Does the layer │
│ context be │ │ current enough │ │ respect your │
│ surfaced at │ │ for an agent │ │ existing access │
│ query time? │ │ to act on? │ │ controls? │
└─────────────────┘ └─────────────────┘ └─────────────────┘
(The three hidden vectors of agentic data engineering)
- Retrievability: Can the right piece of context actually be surfaced and fed to the model at query time? If your vector embeddings or keyword search algorithms can’t pull the exact documentation required, the agent fails before it even begins to reason.
- Trustworthiness: Is the retrieved data current enough to act on? If an agent is autonomously managing an engineering pipeline or an undocumented business rule, stale metadata will cause it to trigger broken builds or corrupt system states.
- Permissioning: This is the most glaring vulnerability in enterprise AI strategy right now. Does your data retrieval layer strictly respect your existing corporate access controls? If an agent has broad read-access to fragmented enterprise knowledge bases to maximize its helpfulness, how do you guarantee it won’t overexpose sensitive payroll, HR, or compliance data to an unauthorized end-user?
Unsurprisingly, organizations that successfully navigate these three dimensions achieve vastly superior outcomes in foundational data quality, asset-level governance and change management. And this operational edge is heavily backed by capital strategy. Research by the McKinsey Global Institute on “superstar” companies reveals top-performing market leaders consistently invest two to three times more in R&D and intangible assets — such as data, software and intellectual property — than their peers.
Taming the Stochastic Engine: Architecture vs. Prompts
The meat of our technical debate focused on orchestration layers. When building autonomous workflows, how do you force a probabilistic LLM to behave reliably inside a deterministic enterprise application?
A major pain point raised by IT leaders is the reality of system integration. The average enterprise is an absolute spaghetti bowl of legacy infrastructure, averaging nearly 897 applications, the vast majority of which are completely disconnected. Fully 95% of IT leaders report that these severe integration hurdles directly impede their AI implementations.
When you try to drop a fluid, non-deterministic AI agent into a heavily fractured application stack, a single brittle prompt or a minor upstream API schema change can completely break a workflow that had run perfectly for weeks.
The solution discussed by our roundtable peers is to shift entirely away from the concept of a prompt-engineered monolith and move toward strict, deterministic boundaries outside of the AI model itself. The rule of thumb we establish at GAP is simple: Let the AI do only what the AI is exceptionally good at — things like text synthesis, semantic parsing and generation. Leave the execution, sequencing and business logic to deterministic code.
To achieve this, sophisticated engineering teams are building highly structured, orchestrated pipelines utilizing four non-negotiable architectural guardrails:
- Constrained Output Schemas: Instead of allowing models to return raw, unpredictable natural language, engineers are utilizing strict function calling to force structured JSON outputs. This single move dramatically reduces the surface area for hallucinations and ensures downstream systems receive data they can actually parse.
- Deterministic Guardrail Layers: Implementing hard-coded, rule-based pre- and post-processing validation code. If an AI agent generates an output that falls outside of pre-approved enterprise parameters (e.g., trying to approve a credit limit or a code change beyond its allowed threshold), the wrapper intercepts the output and flags it before it ever hits downstream systems.
- Confidence Thresholding: Agents must be programmed to output a confidence score alongside their telemetry data. If a decision falls below a mathematically defined confidence threshold, the pipeline automatically routes the transaction to a human review queue rather than auto-acting on a guess.
- Idempotent Actions: In complex, multi-step autonomous workflows, networks drop and APIs fail. Agent actions must be designed to be completely idempotent. If an execution step runs twice or crashes mid-execution, the system state must remain consistent without duplicating transactions or corrupting databases.
By establishing these strict programmatic wrappers around API calls and tool executions, you minimize risk zones and transform a chaotic AI model into a predictable software component.
The Upcoming Telemetry Crisis
As our session concluded, a senior CTO raised a question that hung heavily over the room: “When an autonomous pipeline inevitably makes an unpredictable move or encounters an edge-case error, how long does it take your engineering team to actually trace the root cause with your current logging and telemetry tools?”
Traditional software logging is designed for static code paths; it tracks inputs, errors and outputs. But if an agent loops through five different reasoning steps, reframes its own queries and then encounters a failure on step six, standard APM tools are completely blind.
Without highly specialized agentic telemetry to track state changes, prompt versions, retrieved contexts and model confidence scores at every hop, debugging an autonomous system becomes an engineering nightmare. If your team cannot reproduce the failure mode, they cannot fix it.
Building this technical foundation — where data is contextually retrievable, orchestration layers enforce absolute determinism and full system telemetry is live — is the ultimate prerequisite for enterprise scale. But once the architecture is locked down, you face an even bigger hurdle: Enterprise Trust.
In our final installment, Part 3: Trust, Governance and the New Operating Model, we will tackle the human and operational side of the pipeline. We will explore how agentic workflows are fundamentally transforming day-to-day developer roles and where to draw the hard line for Human-in-the-Loop oversight. And we’ll discuss the existential question keeping executive leadership awake at night: Who actually owns the liability when an autonomous agent makes a rogue decision that impacts the bottom line? Stay tuned.
