Gartner estimates only approximately 130 of the thousands of vendors claiming agentic AI are genuinely agentic. Here is what the studio model actually delivers, and four questions that expose the gap in any demo.
TL;DR
- The “50+ agents out of the box” claim is a seat-expansion metric, not an architectural specification.
- Most vendor agents are prompt variations on a shared runtime with no cross-agent context or centralized governance.
- Forrester: three in four firms building aspirational agentic architectures independently will fail.
- Forward-deployed engineering teams are the structural consequence of the studio model, not an add-on service.
- McKinsey (April 2026): eight in ten companies cite data limitations as a roadblock to scaling agentic AI.
- Download the full architectural comparison: Beyond the Hype: Agent Studios vs. Enterprise Agentic AI
Agent Debt is the compounding operational liability an enterprise takes on when it deploys task-doing AI agents faster than it can govern, orchestrate, and tie them to business outcomes. The
foundational piece introduced the concept. The self-assessment provides the diagnostic. This blog identifies the architectural source of the debt in the DIY studio model.
Why do procurement AI vendors promise 50 or more agents?
The number is a seat-expansion metric. Most major source-to-pay suites have shipped a no-code canvas that lets business users create agents without waiting on a technology roadmap. The vendor measures success in agents created because that drives seat utilization and contract expansion. The individual agents typically pass their own tests. The problem is what happens when there are twelve of them, built by four teams, wired point-to-point with no shared governance layer underneath.
Gartner estimates that of the thousands of vendors currently marketing agentic AI, only approximately 130 are genuinely agentic. The rest are something simpler: prompts on a runtime, chatbots renamed, automation rebranded. The analyst community calls this agent washing. The studio model is its industrial-scale delivery mechanism. Every new agent studio release compounds the problem: more blank canvases sold, more agent-washed software deployed at enterprise scale.
What is the actual architecture behind a no-code agent studio?
Four marketing claims map to four architectural realities. Each gap is documented in the whitepaper Beyond the Hype.
“50+ agents out of the box”: Prompt variations on a shared runtime. Not independent reasoning systems.
“Autonomous intelligence”: Limited reasoning beyond the immediate task. No cross-agent context.
“Built-in governance”: Partial dashboard visibility. Not auditable decision lineage.
“Scalable automation”: Isolated execution with no shared state. Different agents reason from different data.
The gap is not a matter of vendor maturity. It is structural.
Is built-in governance the same as audit-ready governance?
It is not. Built-in governance in the studio model typically means a dashboard showing agent activity: runs, completions, exceptions. This is visibility, not accountability.
Audit-ready governance requires the ability to produce a specific, complete, timestamped record of why a particular agent made a particular decision, which policy it applied, and whether that policy was current at the time. A dashboard does not answer those questions. The gap surfaces at the first audit, and again at any procurement exception that requires a decision trace.
Why do three in four firms fail when building agentic architectures on their own?
The failure mode is architectural complexity, not ambition.
Forrester’s Predictions 2025 research finds that three in four firms attempting to build aspirational agentic architectures independently will fail, citing four requirements most enterprise technology teams cannot assemble simultaneously: diverse AI models, sophisticated RAG stacks, advanced data architectures, and niche agentic expertise.
The DIY studio appears to abstract this complexity away. The canvas is no-code. Agents deploy in an afternoon. The demo works. What the demo does not show is what happens at the seams between agents, where the complexity lives, and what it costs when it compounds. Those seams are precisely where Agent Debt begins to accrue.
What is a forward-deployed engineering team and why do studios need one?
A forward-deployed engineering team (FDE) is a group of vendor-provided specialists embedded at the customer site to manage and extend the agent estate. The framing is enablement. The function is often closer to permanent operations.
The structural reason is data.
McKinsey’s April 2026 research finds that eight in ten companies cite data limitations as a roadblock to scaling agentic AI. Agents without shared persistent context must re-derive their understanding of suppliers, contracts, and policies on every run. The inconsistencies that result require human diagnosis and correction. FDE teams are that correction, made recurring.
The incentive structure is the problem. A vendor charging per agent or per seat profits from agent proliferation. More agents mean more integration complexity, more prompt drift, and more FDE work. The disease and the cure, billed to the same account.
What does a genuinely agentic procurement platform look like?
The architectural difference is the starting point. A studio begins with a blank canvas and asks what agents can be built. An enterprise agentic AI platform begins with a governed Intake-to-Outcomes workflow and asks what agents that workflow requires.
In January 2026, Singapore’s IMDA published the world’s first Model AI Governance Framework for agentic AI. Its core principle: governance built into the system from design, not applied after deployment. Every control, every policy boundary, every audit trail is defined before any agent is activated, not bolted on after the first demo. A workflow-first platform operationalizes this by design. A studio can only attempt to retrofit it afterward. The framework covers agent boundaries, risk identification, human oversight checkpoints, and what the framework calls agentic guardrails: structural controls baked into how the system operates, not monitoring layers applied on top of it after the fact.
What should you ask in a vendor demo to separate real from agent-washed?
Four questions expose the architectural gap. Ask them in any sequence.
- Context sharing: Can your sourcing agent pass live supplier context to your contract agent mid-workflow without a manual step? A genuine orchestration layer handles this automatically.
- Exception handling: If an invoice fails a match at step four of a five-step process, what handles the exception without human intervention? A platform routes and logs it. A studio alerts and stops.
- Audit reconstruction: How long to produce a complete record for one specific agent decision last month? Minutes is a platform. Hours requiring engineering support is a studio.
- Policy propagation: If your supplier approval threshold changes tomorrow, how many places in the agent estate must be updated? One place is a centralized policy layer.
The Merlin Agentic AI Platform is built to answer all four at the architecture level: agents embedded in governed Intake-to-Outcomes workflows, centralized policy, shared context, and audit by design.
What does it mean to move from Source-to-Pay to Intake-to-Outcomes?
Source-to-Pay is a transaction map. Intake-to-Outcomes is an accountability structure.
Isolated agents do tasks. A sourcing agent drafts an RFP. A contract agent checks a clause. Each passes its own test. None of them answers for whether the savings the negotiation was supposed to capture were realized, or whether the spend that followed was compliant.
Zycus built the Merlin Agentic AI Platform around the Intake-to-Outcomes model because the alternative, a studio of task-shaped agents with governance bolted on afterward, is precisely the architecture that produces Agent Debt structurally. The metric is not agent count. It is the outcome, fully accountable from intake to close.
Beyond the Hype: Agent Studios vs. Enterprise Agentic AI. The architectural case for governed agentic AI in procurement. Published by Zycus. → Download the whitepaper
FAQs
Q1. What is agent washing and how widespread is it in the procurement AI market?
Agent washing is the practice of rebranding existing AI assistants, chatbots, and workflow automation tools as agentic AI without delivering substantive agentic capability. Gartner estimates that of the thousands of vendors marketing agentic AI, only approximately 130 are genuinely agentic. In procurement specifically, most “agentic” sourcing and contract tools are prompt-based systems on a shared runtime, not independent reasoning systems capable of coordinating across a full procurement workflow.
Q2. What is the difference between a DIY agent studio and an enterprise agentic AI platform?
A studio starts with a blank canvas: users create agents, configure them, and connect them to systems. An enterprise platform starts with the governed workflow: agents are embedded into business processes that already carry controls, audit trails, and policy enforcement. The starting point determines the trajectory. A studio adds governance later. A platform builds it in from day one, making it structural rather than retrofitted.
Q3. Can a DIY agent studio ever scale to enterprise-grade procurement requirements?
The challenge is architectural rather than a question of effort or platform maturity. Forrester finds that three in four firms building aspirational agentic architectures independently will fail, citing the complexity of diverse model requirements, RAG stacks, advanced data architectures, and niche expertise. The firms that succeed do so by working with platforms that provide this architecture pre-built, not by assembling it on top of a blank canvas studio.
Q4. What is a forward-deployed engineering team and what do they actually do?
A forward-deployed engineering team is a group of specialists embedded at a customer site, provided by the AI platform vendor. In practice, FDE teams manage the Agent Debt the platform accumulates: diagnosing prompt drift, resolving integration failures, patching governance gaps, and rebuilding context that agents lost. The vendor’s revenue grows with agent count and services engagement, so there is no structural incentive to reduce the complexity that makes the FDE team necessary.
Q5. How do I know if a vendor’s agents are genuinely agentic or rebranded automation?
Ask four questions in any demo. Can one agent share live context with another mid-workflow without a manual step? If an exception occurs at step three of a five-step process, what handles it without human intervention? How long does it take to produce a complete audit record for a specific agent decision? And if your procurement policy changes, how many places must be updated? A genuine platform gives confident, architectural answers. A studio defers most of them to implementation.
Q6. Why does the studio model keep requiring more engineering support over time?
Because the studio model measures success in agents created, not outcomes delivered. Each new agent adds an integration to maintain, a prompt to tune, and a governance gap to manage. As the estate grows, integration complexity grows non-linearly. The FDE team is the recurring cost of that compounding complexity, and because the vendor’s revenue depends on the estate remaining complex, there is no structural incentive to simplify it.
Q7. What does Forrester mean when it says three in four firms building agentic architectures will fail?
Forrester’s prediction is about the organizational and architectural complexity of building genuine agentic capability independently: diverse AI models, sophisticated retrieval-augmented generation stacks, advanced data architectures, and niche expertise that most enterprise technology teams do not have. The prediction is not about AI capability being insufficient. It is about the conditions required to make agents coordinate reliably at scale with governance, and how structurally hard those conditions are to assemble from a blank canvas.
Q8. What is the Intake-to-Outcomes model and how is it different from Source-to-Pay?
Source-to-Pay describes the process steps: sourcing, contracting, purchasing, payment. Intake-to-Outcomes describes the accountability structure: every business request that enters the system is tracked through to the realized outcome it was supposed to deliver. Source-to-Pay counts transactions. Intake-to-Outcomes counts savings realized, compliance maintained, and decisions that can be explained. Agents built inside an Intake-to-Outcomes architecture answer for outcomes. Agents built in a studio answer for tasks.
Related Reads:
