Blog

The Decision That Sinks AI Agent Projects Is Made Before the Project Starts

Gartner has been warning for over a year that agentic AI projects face escalating costs and unclear business value. It now predicts that 40 percent of enterprises will demote or decommission autonomous AI agents by 2027, after governance gaps surface in production. And McKinsey's latest State of AI survey finds that despite near-universal adoption, only 39 percent of organizations report any enterprise-level bottom-line impact from AI.

So why do these projects fail when the models they run top every benchmark? Aren't they built by capable teams using the same tools?

The reason is often not the model itself, but how they harness its power. Harnessing that power requires the right agent architecture, a choice most projects never consciously make. It gets settled by default, before the task itself is examined, usually as "pick the strongest model, hand it the keys, and give it tools."

The model is not an agent

An agent is much more than the model inside it. The model supplies the reasoning, but it is only as capable as the context the rest of the agent delivers to it. Box's State of AI in the Enterprise 2026 found that 96 percent of organizations say agents must access company-specific content to be effective, yet only 36 percent have connected their agents to trusted internal content.

The agent architecture determines that context. It sets what data the agent sees, when the model is invoked, what executes its decisions, and whose identity its actions carry. It drives the agent's reliability, security, and cost curve, and decides who can build it. And those consequences surface in production, long after the choice is made.

Five architectures account for nearly all enterprise deployments today.

  • Hosted platform agents (Salesforce Agentforce) are assembled from the platform's topics and actions and governed by its trust layer.
  • Framework-built agents (LangGraph, Google ADK) give engineering teams ownership of the orchestration code and the loop.
  • Provider-managed agents (Anthropic, OpenAI, Bedrock, Vertex) run the loop and the sandbox on the provider's infrastructure.
  • Self-hosted skills agents (OpenClaw, Hermes) run an LLM chat loop guided by natural-language skill files, re-interpreted on every run.
  • Compiled workflow agents (Prompt One; agentic RPA) use AI to generate the workflow code once, at authoring time; runs execute as deterministic code, calling the model only where judgment is genuinely required.

None of these is universally right. That is why a conscious decision is so important.

Eight questions before you build

In our whitepaper, Choosing an Enterprise Agent Architecture, we lay out a four-step framework that profiles the task, derives the requirements, evaluates the economics, and only then matches the workflow to an architecture. Answer its eight questions and you'll have the evidence you need to make a deliberate choice rather than a default.

  1. Are the steps knowable in advance, and does the job repeat?
  2. Is judgment required, and where exactly does it live?
  3. Are updates attended, unattended, or gated by human approval?
  4. Does the workflow touch untrusted inputs?
  5. Who is responsible when it acts, and can you prove what happened?
  6. Who can build it, engineers or the team that owns the work?
  7. What can they build, including approval queues and writes to systems of record?
  8. What does it cost to operate, at your real schedule and fleet size?

If the steps are knowable and the job repeats, re-deriving the plan with a model on every run adds variability and cost to work that should produce the same result every time. If the workflow reads untrusted input such as inbound email, resumes, or support tickets, an architecture where instructions and data share the model's context is an injection risk by construction. If compliance asks "why did the agent do that," an audit trail of what the model happened to decide is not the same as replay, where the same inputs reproduce the same steps.

Where the answers converge

Evaluate the typical enterprise IT backlog against the framework and different workflows land in different places. Conversational judgment on data within platforms like Salesforce points to Agentforce, ad hoc exploration to skills agents, bespoke products to frameworks, and UI-only legacy systems to agentic RPA.

Most enterprise agent workflows are recurring and structured with cross-system dependencies, and often best delivered as compiled workflow agents. They answer the eight questions the same way every time. The steps are knowable, the judgment is concentrated, the cadence is unattended, the input is untrusted, audit obligations apply, and per-run inference cost must be managed.

A backlog, though, holds only the workflows the enterprise already knows about. A bigger opportunity is one that can only be imagined, the new AI-enabled workflows envisioned by the people who actually do the work. Capturing that opportunity means giving those people a self-serve way to build agents, one that doesn't jeopardize enterprise security, compliance, or governance.

The coming requirement for self-serve authoring and deployment pins down two of the eight answers. Question 6 asks who can build it, and the answer becomes the team that owns the work. Question 5 asks who is responsible when the agent acts, and handing authoring to that team only works if governance holds by default. Here the choice narrows from an architecture to an implementation. Prompt One is unique in that it implements compiled workflow agents in a self-serve offering. Anyone who can describe a workflow in natural language can build and deploy an agent, and the platform compiles the description to executable code that runs under existing identity and audit controls. How that implementation works, from the agent's workspace to its approval gates, is the subject of a follow-up post.

As for question 8, we tested the economics directly, building the same resume-screening workflow twice, once as a skills agent and once as a compiled workflow agent, and running both against the same fifteen applicants. The compiled agent cost roughly 11 times less per run, and the gap is architectural, not a pricing artifact. Caching cannot close it. The full measurement is in the follow-up post and the whitepaper.

Where to start

Agent architecture will not decide every project's fate on its own. But the enterprises that choose it deliberately will be far better represented among the projects that survive. If your first agent needs to succeed, pick the workflow where the framework's answer is reliable, low-cost, and buildable by the team that owns the work.

The full framework, the decision matrices, the measured comparison, and three worked examples are in Choosing an Enterprise Agent Architecture. You can read it on this site, or download the PDF.

← All posts