Skip to content
Pyrana
For business leaders
Vendor evaluation
Agent sprawl

The tenth application is the one that matters

Point solutions, suite extensions, cloud agent stacks, and application platforms all get one agent live. They diverge at the tenth application and the first incident. How to evaluate vendors for app number ten, and what to put in the RFP.

Eric Tarnowski
September 9, 2026
7 min read

Every first agent looks the same

You are evaluating vendors for your first agent, and every demo looks the same. A customer service agent from Sierra, a contract reviewer from Harvey, a Copilot Studio bot in Teams, an Agentforce agent in the CRM, something an engineer built on AWS AgentCore over a weekend, or an App on a platform like ours. Each takes 20 minutes to show and each one works.

That is the wrong decision to be making. The first agent will go live under any of them. What you are actually choosing is what the tenth application will cost and what the first incident will look like.

Four ways to get there

There are four approaches, and I will be fair to each of them, because I have bought or built under three of them.

Buy point solutions. Sierra for service, Harvey for legal, Jasper for marketing. They are fast and they are good in their lane. Each one arrives with its own identity model, its own idea of what a permission is, its own audit format, its own knowledge grounding, and, increasingly, its own agent builder.

Extend your suite. Copilot Studio, Agentforce, ServiceNow. Cheap and quick while the work stays inside the suite's boundary, and most of your real processes cross it. The close touches SAP, a bank portal, and a SharePoint folder. The suite's agent sees the part that lives in the suite.

Build on a cloud agent stack. AWS AgentCore, Microsoft Foundry, Google's agent platform, Databricks. You get primitives: a runtime, memory, identity, a policy engine, a gateway, evaluations, each configured and billed separately. You build the application: authorization that people and agents share, approval policy, audit, durable execution, versioned configuration, and then you maintain all of it.

Adopt an agentic application platform. Governance and context are built once, generically, and each application is composed on top. This is what we sell, so weigh my view accordingly.

All four get the first agent live. They diverge at the tenth application and the first incident.

Where most companies are right now

The average enterprise already runs 12 AI agents and expects that number to grow 67 percent within two years, and 50 percent of those agents operate in isolated silos with no shared data, coordination, or handoffs (Salesforce, 2026 Connectivity Benchmark Report, February 2026). Ninety-four percent of IT leaders say agent sprawl is raising complexity, technical debt, and security risk, and 12 percent have a centralized platform to manage it (OutSystems, April 2026). Two thirds of CIOs and CTOs say they are held accountable for AI systems they do not fully control, 70 percent say teams are deploying faster than IT can track, and large enterprises expect to be running about 1,660 agents each by 2027 (IBM Institute for Business Value, June 2026).

Twelve agents is the tenth application, give or take. This is not a forecast about someone else. It describes the estate most readers of this piece already have, assembled one first agent at a time. And the consequence Gartner predicts for it is specific: by 2027, 40 percent of enterprises will demote or decommission autonomous agents because of governance gaps that surface only after a production incident (Gartner, May 2026).

The cost curve

Think about cumulative effort from application one to application ten under each approach.

Point solutions go superlinear. Ten applications means ten identity models to map to your directory, ten audit formats to reconcile for the auditors, ten places the same policy has to be restated, and integration glue for every pair of agents that has to share context, governed by none of them. The tenth application costs more than the ninth, because it has nine neighbors to be wired to.

The suite is flat until it hits the boundary, then steps. Applications one through four live comfortably inside it. The fifth needs a system the suite does not own, and from that point you are either paying the suite's price for a connector that does part of the job, or building outside the suite with none of its governance.

Build is linear with a high intercept. The layer below the waterline, fine-grained authorization, approvals, audit, durability, secrets, versioning, is expensive, security-critical, and invisible when it works. Teams under-build it for the first application and then discover, at the first incident, which parts were skipped. Each subsequent application reuses some of it and re-implements the rest, and the platform team you did not plan to have becomes the bottleneck.

The platform has a real intercept, adopting it, connecting SSO, loading the first policies and documents, and then flattens, because governance and context are reused rather than rebuilt. Every new application starts further ahead than the last, and it is the only one of the four curves where the tenth application costs less than the first.

The first incident

The incident will be ordinary. An agent paid a vendor twice because the provider timed out and it retried. A board pack cited a policy that was superseded in March. A worker in one business unit was shown a document from another.

Four things get asked for in the room: the identity the agent acted under, the authority it was acting on, who approved the action and against which version of the rules, and the record itself, with the version of the application that ran.

Under point solutions, the answers are in the vendor's console, in that vendor's format, to the extent that vendor kept them. Under the suite, the answers are complete for the part inside the suite and absent for the part outside it. Under a build, the answers depend on what the team got to before launch, and the missing one is usually the reason for the incident. Under a platform, the answer is one record, the same shape for every application, written before the call ran.

What to hold every approach to

Regardless of what you pick, the tenth application needs five things from the first, and you can ask for them in an RFP.

One identity model shared by people and agents, so every agent exists in your directory with its own credentials in each system it touches. Permission that correlates what a caller may do with which data, as one grant, rather than a role in one place and a filter in another. Approval as a policy over the actual amounts and parties, with a named approver and a record, rather than a flag on a tool. One audit record shape for every application, written before anything runs. And context that is shared across applications under those same permissions, with provenance, so the tenth application knows what the first nine learned.

How we handle the tenth application at Pyrana

An Agentic App is defined as configuration, compiled into an immutable, content-digested version, and activated by moving one pointer. Every one of the five doors into it (the App UI, chat, API, MCP for other agents, and schedules or events) passes the same admission check: who is calling, under what authority, on which data, with what approval. It fails closed, the record is written first, and unauthorized items are absent from results rather than "denied."

The pieces that make the tenth application cheap are the ones you define once. Access profiles correlate what a caller may do with which slice of data as one grant, and the "reviewer in Business Unit A" profile written for the first App is reused by the tenth. Approval policy over typed arguments, with frozen invocations and named approval lanes, is built and enabled per App; the finance lane you configure for the close is the same lane vendor onboarding uses. Every call, in every App, produces one AppExecution record of the same shape. Your own domain code lives in your repository as an extension, receives short-lived delegated tokens, and never holds external credentials; two client extensions run in production today.

Context compounds through cortIQ (formerly the Context Engine). Documents and system data are extracted once into Context Units (CxUs), each a single claim with verbatim supporting quotes, provenance, and a content hash, stored in a knowledge graph. Every App retrieves from the same graph under its own permissions, and every run records what was retrieved, what was injected into the prompt, and what was cited. When a policy is superseded, the units that depend on it change once, for every App.

An illustration. A financial services firm builds its first App for close review in about six weeks, most of it spent on SSO, the access profiles, the delegation-of-authority policy, and loading the policy library into cortIQ. App four is collections. App nine is vendor onboarding. App ten is contract review for procurement, and it reuses the finance approval lane, the business-unit profiles, and the audit record, and it cites the same delegation-of-authority units the first App loaded. It ships in under two weeks because there is nothing below the waterline left to build. What comes next for us is a registry of published outputs, so that the close App's approved report has a stable name the contract App can cite; today that sharing runs through cortIQ and configuration.

Questions for the RFP for application ten

Put these in writing and score the answers.

  1. Show me one operation reachable from your UI, from chat, from an API, and from a schedule, and the record each path produced. Are they the same shape?
  2. Where does an agent's identity live, in your product and in my systems, and how are its credentials scoped per system?
  3. Define the approval for a payment above 25,000 USD: what is frozen, who approves, what happens if the approver's membership changed yesterday, and what happens if the provider times out?
  4. When the tenth application needs a policy the first one already loaded, what is re-done?
  5. Show me the record of one call that was refused.

Any vendor who can answer those for application one has told you what application ten will cost.

Sources

Continue the Conversation

Building production-grade agentic AI requires context, orchestration, and human-in-the-loop design. We'd love to show you how Pyrana delivers it end to end.

Request a Demo