AI Agent Platform: 5 Control Questions Before You Buy

An AI agent platform is software that lets an agent decide and then act inside your real systems. It holds the model, the tools, the memory and the run loop in one place. Choosing one in 2026 is no longer a features question. It is a control question, because every platform can call your APIs and only some can tell you what they called, on whose authority, and what it cost.

Our position is narrow and testable: five questions eliminate candidates faster than any feature matrix, and all five concern what the platform does after the model decides. We call them the Five Control Questions, and you can run them in one sitting before a single demo. Why we hold that position is visible in how buyers talk when nobody is selling. On Hacker News in January 2026, a developer posting as techbuilder4242 asked the room a question no vendor page answers: "What stops your agent from executing unintended actions (deleting records, unauthorized transactions)?" The thread drew one reply. Two months later, on a separate thread about monitoring agents in production, a reader gave the blunt version: "I can't imagine giving an agent access to production."

The short answer: Score every AI agent platform out of 10 on identity, authority, policy locus, spend caps and reconstructable proof — two points each — and refuse to pilot anything scoring under 6, because every capability gap below that line is one your team pays for in incident response rather than in licence fees.

Last updated: July 30, 2026.

The Five Control Questions describe a layer, not a feature list: every agent action passes the same five checks before it reaches a business system.

One disclosure first: we have not run a head-to-head bake-off of the six platforms below on a common task, and we will not imply we did. Every price, unit and capability statement comes from a vendor's own published documentation, fetched 30 July 2026 and linked so you can re-check it. The judgement is ours; the measurements are theirs.

What an AI agent platform is, and the three things it is not

An AI agent platform is the runtime and control surface for software that reasons before it acts. It supplies four things a bare model API does not: a loop letting the model take several steps toward a goal, a tool layer that turns "call the CRM" into an authenticated API request, memory that survives the end of a conversation, and an operational envelope of logging, retries and limits around all of it. A product with the first two and not the last two is a framework, not a platform.

The boundaries matter more than the definition, because most buying mistakes are category errors.

It is not a chatbot builder. A chatbot ends at the reply. An agent's output is a side effect in another system: a refund issued, a record updated, an email sent. That difference is why the security literature treats agents as a distinct class. OWASP's Top 10 for LLM applications gives the failure its own entry, LLM06:2025 Excessive Agency, defined as "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM." OWASP traces it to three root causes: excessive functionality, excessive permissions, excessive autonomy. Two of the three are procurement decisions, not model decisions. None of its listed mitigations is a smarter model; one of them is requiring human approval for high-impact actions.

It is not an agent framework. LangGraph, CrewAI, AutoGen and the OpenAI Agents SDK are libraries you import. They give you the loop and the tool-calling contract and leave hosting, identity, quotas and audit to you. Often the right choice, but a different purchase, and the two get conflated constantly by roundups that list a Python library beside a per-seat SaaS product as though a buyer were choosing between them.

It is not an iPaaS with a language model bolted on. Zapier, Workato and n8n move data between systems on deterministic triggers. Reasoning changes the risk profile: a deterministic integration fails the same way every time, an agent differently every time. Non-determinism makes agents useful on messy inputs and hard to certify.

One distinction buyers discover late: a platform can be excellent at building agents and useless at operating them. A practitioner on that monitoring thread put it better than any vendor page — "observability and governance cannot live inside the agent framework". Once Team A builds in LangGraph, Team B in CrewAI and Team C in raw Python against a model API, framework-level monitoring gives three partial records and no answer for a compliance officer. Control has to live somewhere both frameworks report into.

Why platform selection became a control question in 2026

Agentic deployment moved faster than agentic oversight, and the gap is now measured rather than asserted. Salesforce's 11th annual Connectivity Benchmark Report, run with Vanson Bourne and with input from Deloitte Digital, surveyed 1,050 IT leaders across nine countries in October and November 2025. The UK cut of that survey covers 100 IT leaders at organisations of 1,000 employees or more. It reports that "69% of UK organisations report that most or all teams and functions have adopted AI agents," while "only 56% of organisations have a centralised governance framework with formal oversight for their agentic capabilities." Adoption is broad; the controls are a coin flip.

A note on that pair of numbers, because it is a small lesson in how this category gets discussed. Secondary coverage of the same report circulated an 89% / 54% version of those figures. We could not reconcile it with the vendor's own published release, so we quote the vendor's page and not the write-ups of it. If you see 89% attributed to this study, check which cut of the sample it came from.

The security picture is sharper, from a source with no product to sell. In January 2026 the Center for AI Standards and Innovation, housed within NIST, published a Request for Information on security considerations for AI agents. That is the US government formally asking industry how to measure something it does not yet know how to measure. The framing is blunt: "AI agent systems are capable of taking autonomous actions that impact real-world systems or environments, and may be susceptible to hijacking, backdoor attacks, and other exploits." Comments closed 9 March 2026. When a standards body opens an RFI, the standard does not exist yet, so for this procurement cycle, your contract terms and platform choice are the control.

How exploitable is it? NIST's own evaluation work put a number on hijacking. In a technical blog published 17 January 2025, NIST researchers reported "an increase in attack success rate from 11% for the strongest baseline attack to 81% for the strongest new attack" against an agent built on Claude 3.5 Sonnet using the AgentDojo framework. The point is the delta, not the model: the same agent went from mostly-resistant to mostly-compromised because someone spent effort on attack rather than defence. The pattern generalises. A large-scale red-teaming competition run with Gray Swan and the UK AI Security Institute found that "across more than 250,000 attack attempts from over 400 participants, at least one successful attack was found against all of the target frontier models."

Data-currency note: the 11%-to-81% result is from January 2025 and remains NIST's cited baseline in its own 2026 RFI reading list. The March 2026 competition analysis broadens it rather than superseding it.

So the model layer will not save you and the standards layer has not arrived. That leaves the deployment layer, which is where survey data says organisations are thinnest. Gravitee's State of AI Agent Security survey of 750 senior technology leaders across the UK and US, updated in April 2026, reports that "48% of production AI agents are running unsecured," that "54% of organisations have experienced or suspected an AI agent security or data privacy incident." The figure we find hardest to look away from: "only 7.2% of organisations have a named individual with formal accountability." Gravitee sells into this problem, so discount accordingly. The direction matches the Salesforce data from an unrelated vendor with a different sample.

The buying question has inverted. In 2024 it was "can this platform build the thing?" In 2026 nearly all of them can, so what separates one enterprise AI agent platform from another is whether your security team can live with the result. AI agent governance stopped being a follow-up project and became a selection criterion.

The Five Control Questions

Five questions, two points each, ten available. Each has a demo-day test you can run in minutes and maps to a failure that has already happened somewhere. Ask them before the feature walkthrough; they will shorten it.

Question 1: Identity — what does the agent authenticate as?

The most diagnostic question in agent procurement. Three answers are possible and one is acceptable at scale: the agent has its own non-human identity with a named owner, or it borrows a human's OAuth token, or it shares a service account with every other agent. Borrowed tokens mean the audit log says a person did it. Shared service accounts mean it says "the platform" did it. Neither is attributable, and attribution is what you need at 2am.

Scoring: 2 if every agent gets a distinct machine identity with an owner, a scope and an expiry, and offboarding that identity is one action. 1 if identities exist but expiry or ownership is manual. 0 if the agent acts as the user who triggered it, or as one shared key.

This is where the standards conversation is furthest along and the products furthest behind; see our earlier analysis of owner, scope and expiry for non-human identities. For the security community's version of the argument rather than ours, this SecTor 2025 keynote makes the case at length and sells nothing:

Question 2: Authority — what can it touch, and how fast can you take that away?

Authority is not "which connectors are available." It is action-level: can this agent read the CRM but not export from it? Refund under $50 but not over? Most platforms scope per integration: you grant Salesforce, and the agent can do anything that credential can. That is OWASP's "excessive permissions" root cause, delivered by product design rather than mistake.

Scoring: 2 if scopes combine tool, action and data class, a human approval gate can be attached to a named action class, and a single revocation kills the agent's access everywhere. 1 if scoping is per-integration only. 0 if the agent inherits a credential's full rights.

Ask for the revocation demo specifically: "remove this agent's access to one system, leave the other four intact, show me the request that then fails." Vendors who cannot will describe their roadmap. Write the date down.

Question 3: Policy — where does the rule live?

If the rule stopping your agent doing something dangerous is a sentence in a prompt, you do not have a policy. You have a suggestion inside the attack surface. Prompts are not versioned by default, not reviewable outside the builder, not testable, and, as NIST's hijacking numbers show, manipulable by the data the agent reads.

Scoring: 2 if policy is a separate, versioned artifact evaluated outside the model's context, with a record of denials. 1 if there is a guardrail layer but it is configured per-agent with no central view. 0 if the answer is "you write it in the system prompt."

There is movement worth crediting. Google's agent platform pricing page documents "Semantic Governance Policies" as "natural language constraints that you configure to govern AI agents through their tool calls," billing from 1 August 2026. A vendor putting policy evaluation on a meter admits it is a layer, not prompt text.

Question 4: Spend — can you cap it per agent, before the invoice?

Agent spend behaves unlike seat spend. An agent in a retry loop can burn a quarter's budget over a weekend with nobody logged in. The question is not "do you have a usage dashboard"; everyone does, and a dashboard describes money already spent. It is whether a hard limit exists per agent, enforced at request time, denominated in something finance recognises.

Scoring: 2 if you can set a per-agent cap in currency, enforced before execution, with alerts at a threshold you choose. 1 if caps exist at tenant or environment level only. 0 if the control is a report.

Tenant-level caps are the common case, with a specific failure mode: one team's runaway agent starves everyone else. Microsoft documents this openly for Copilot Studio, where enforcement triggers at 125% of prepaid capacity and "custom agents are disabled" tenant-wide. That blast radius is worth understanding before pooling capacity across departments. Our analysis of routing and cost control covers why dollar budgets beat token budgets.

Question 5: Proof — can you reconstruct one action six months later?

This question decides whether an incident becomes a post-mortem or a disclosure. Pick an action the agent took. Can the platform produce the trigger, the inputs, the model and version, each tool call with arguments, the decision points, the identity it acted as, and what it was refused? That last clause is where most platforms fail. A log of successful actions says what happened; a log including denials says the controls were working.

Scoring: 2 if traces are tamper-evident, retained on a schedule you set, exportable, and include refusals. 1 if you get traces but retention or export is limited. 0 if observability means a token-usage graph. Test "tamper-evident" concretely: ask who inside the vendor can edit or delete a trace, and what record that edit leaves.

Another commenter on the same thread named the gap: most tools record that tool X was called and output Y, not why the agent deviated from its plan, and in a post-mortem the deviation is the whole question. We have written up the evidence-grade version separately.

The one-sitting diagnostic: score an AI agent platform in 45 minutes

You do not need a proof of concept to eliminate two thirds of a shortlist. You need documentation and 45 minutes. Run it before any pilot; it is the cheapest step in the evaluation and the only one we would call mandatory.

Then apply the bar. It is arguable, so here is the reasoning rather than just the number.

Why 6 and not 5 or 7? At 6 you have roughly one full control missing and two partial. One missing control is a project with an owner. Two is a second platform you did not budget for, staffed by people who thought they were buying software. The bar is a judgement call, so move it if your risk appetite differs. But set it before the demo, because afterwards you move it for the wrong reasons.

Run this on documentation, not on a call. Sales engineers answer in the most favourable reading; documentation answers in the reading the support team lives with. Then re-test each score against a named artefact in the demo: a permissions screen, a policy object, a trace export. Good documentation and good product are different achievements.

If the platform is already chosen and scores 4, you are not stuck, you are staffing. The two compensating controls that buy most: a proxy between the agent and your systems that enforces scope and logs every call, and a pre-funded credential with a hard ceiling so the budget cap lives outside the platform that lacks one.

What AI agent platforms actually cost

The finding that surprised us most is not a number. It is that no two major platforms bill in the same unit, so the phrase "AI agent platform pricing" has no shared meaning across the category. Ask five vendors for AI agent platform pricing and you get five answers denominated in five different things. Five vendors, five currencies of their own invention. All figures below come from vendors' own pricing pages, fetched 30 July 2026 and linked; re-check before quoting, because this category re-prices often.

The arithmetic nobody publishes

Because the units differ, the only honest comparison runs one workload through each vendor's own published rates. Take 100,000 agent actions a month, mid-sized rather than hyperscale.

On Copilot Studio, an agent action bills at 5 Copilot Credits per Microsoft's published rate table. That is 500,000 credits, and at $200 per 25,000-credit pack it costs $4,000. Microsoft's own worked example agrees: their order-processing agent triggers four agent actions, costed at 20 Copilot Credits, which is $0.16 at pack rate.

On AgentCore, the same 100,000 actions meter as compute. Assume 20 seconds of one vCPU per action, generous for a tool call, conservative for a reasoning loop. That is 555.6 vCPU-hours, which at $0.0895 is $49.72, plus Gateway invocations at "$0.005 per 1,000 invocations" and model tokens separately.

On Google's Agent Platform, the same compute at $0.085 per vCPU-hour with the first 50 hours free is $42.97, again before tokens.

The spread between credit-metered and compute-metered platforms is roughly 80×, and not because AWS and Google are cheap. The credit price bundles orchestration, connectors, identity plumbing, tenant admin and a support contract; the compute price bundles none of it. You pay for that layer in credits or you build it with engineers. That is the buy-versus-build decision, expressed in the only currency both sides share.

Two cautions, because a number this decisive invites misuse. Our 20-vCPU-second assumption is ours, not a vendor's; halve it or double it and the ratio moves, so treat 80× as an order of magnitude rather than a quote. And none of these figures include model tokens, which on a reasoning-heavy agent often exceed the platform fee on either side. The tokens are the same on both; the layer is what differs.

The pricing you cannot get

We could not verify current published pricing for three names a reader would expect. OpenAI's pricing pages returned 403 to our automated fetches, as did Gartner's research summaries; n8n's and Relevance AI's pricing pages load but render their tables client-side, so the served HTML contained no figures at all. Rather than quote figures we could not re-read, we left those platforms out. An absent row is a gap in our evidence, not a judgement about the vendor.

Six AI agent platforms scored against the five control questions

Uniform blocks, same criteria, scored on documented capability rather than demo impressions. We have not operated all six in production; these scores are documentation-derived, the diagnostic above, run in public so you can disagree with a specific line.

Amazon Bedrock AgentCore

Best for: teams with AWS platform engineers who want the control primitives exposed and will assemble them.

How it answers the five: identity, policy and memory are separately priced products rather than features, which signals they are separately implemented. AgentCore Identity meters at "$0.010 per 1,000 token or API keys requested" for non-AWS resources, and carries no additional charge when used through Runtime or Gateway; Policy bills "$0.000025 per request" for authorization. When a vendor puts a meter on authorization decisions, those decisions exist as objects.

Pricing (fetched 30 July 2026): $0.0895 per vCPU-hour; $0.00945 per GB-hour; Gateway $0.005 per 1,000 invocations; short-term memory $0.25 per 1,000 new events; long-term memory storage $0.75 per 1,000 records per month.

Watch out for: every meter is a line item you must forecast, and the assembly is yours. Spend caps are an AWS-account discipline, not an agent-level feature.

Verdict: highest ceiling on control, highest floor on effort. Score it 8-9 with a platform team, 5 without one. An unassembled control primitive controls nothing.

Google Gemini Enterprise Agent Platform

Best for: organisations on Google Cloud that want policy evaluation as a managed service.

How it answers the five: Semantic Governance Policy is the most interesting thing in this comparison: "natural language constraints that you configure to govern AI agents through their tool calls," evaluated outside the agent's own prompt, with billing commencing 1 August 2026. A direct answer to Question 3. Agent Gateway, Memory Bank and Sessions are similarly separate services with their own meters.

Pricing (fetched 30 July 2026): Agent Compute $0.085 per vCPU-hour above a 50-hour monthly free tier; Agent Memory $0.009 per GiB-hour above 100 GiB-hours; Agent Storage $0.000410959 per GiB-hour above a 1 GiB-month free tier, which works out around $0.30 a GiB-month; Agent Gateway metered as one vCPU-hour per 15,000 API calls.

Watch out for: several meters had not commenced billing when we fetched the page: Skill Registry from 1 July 2026, Semantic Governance Policy from 1 August, Memory Bank and Sessions from 1 September. A capability not yet metered is a capability whose real cost you cannot model. Get the post-commencement estimate in writing.

Verdict: strongest managed answer to the policy question in the set, on a pricing model still settling. Pilot it, and re-forecast in October.

Microsoft Copilot Studio

Best for: Microsoft 365 estates where agents mostly act on Microsoft data and Entra already solves identity.

How it answers the five: identity and authority arrive largely for free because the agent operates inside an existing tenant identity model. Microsoft's documentation states that included usage applies when "the agent operates using the authenticated Microsoft 365 Copilot USL user's identity." Read that carefully. It is convenient, and it is also the borrowed-human-token pattern Question 1 warns about.

Pricing (fetched 30 July 2026): "$200.00/pack/month" per 25,000 Copilot Credits. Classic answer 1 credit, generative answer 2, agent action 5, tenant graph grounding 10, agent flow actions 13 per 100 actions. GenAI Voice 35 credits per minute; Premium GenAI Voice 75.

Watch out for: the enforcement model. Overage triggers at 125% of prepaid capacity and custom agents are disabled, with further invocations rejected, in Microsoft's words, "until capacity is increased or reset." A separate rule covers agent flows, where enforcement "resets monthly when prepaid Copilot Credits are renewed." Read those two together before you need them: the recovery path for a disabled agent is buying capacity, not waiting for the month to turn. Per-agent monthly consumption limits are configurable in the Power Platform admin centre. Use them, because tenant pooling without per-agent caps is how one team's loop becomes everyone's outage.

Verdict: the lowest-friction route to a governed first agent in a Microsoft shop, identity caveat priced in. Score 7-8 there, 4-5 anywhere else.

Salesforce Agentforce

Best for: service and sales teams whose agents work inside Salesforce records and whose value is measured per case.

How it answers the five: authority and audit inherit from Salesforce's own permission and field-history machinery, mature in a way most agent platforms are not. Spend is the clearest of the six: Flex Credits are pre-purchased and consumed per action, with worked examples published per use case.

Pricing (fetched 30 July 2026): Flex Credits "$500 USD/Per 100k Credits"; Conversations "$2 USD/Per conversation"; Agentforce User License "$5 USD/User/Month (Requires Flex Credits)"; Flat Fee Access "$125 user/month"; industry add-ons "$150 user/month"; Agentforce 1 Editions "from $550 user / month" including 2.5M Flex Credits per org per year.

Watch out for: the stacking. A seat licence, a flat-fee tier, credits and per-conversation charges can all be live at once, and Salesforce's own worked examples price a single use case anywhere from 20 to 120 Flex Credits, a 6× spread inside one platform. Model your action mix, not the headline rate.

Verdict: strong on proof and spend, weakest on portability. Everything you build is a Salesforce asset. Score 7-8 if that is already true of your business, and treat lock-in as a stated cost rather than a hidden one.

LangGraph / LangSmith Platform

Best for: engineering teams wanting framework flexibility with a managed control plane for traces and deployments.

How it answers the five: tracing is the strongest axis and it is genuinely good at the deviation question: you can see why a run took the path it took, not just what it called. Identity, authority and spend caps are your application's problem, not the platform's.

Pricing (fetched 30 July 2026): Developer "$0 / seat" with "Up to 5k base traces / mo"; Plus "$39 / seat" with unlimited seats available; Enterprise custom. Usage meters in "LCU" compute units at "$1.50" each and "LSU" storage units at "$1.00" each.

Watch out for: normalised units you cannot decompose. An LCU is "a unit of work done" as the vendor defines it, which makes forecasting an exercise in trusting someone else's normalisation. Run the usage calculator on your real trace volume first.

Verdict: best-in-set on Question 5, near-zero on Questions 1, 2 and 4 by design. Buy it as an observability layer for agents you govern elsewhere, not as the governance layer.

Botpress

Best for: customer-facing conversational agents where volume counts in conversations and the buyer is a business owner, not a platform team.

How it answers the five: conversational scoping is clear and the pricing is the most legible in the set. You know what a conversation costs before you build one. The control questions are largely unanswered at platform level, a reasonable posture for the job it does.

Pricing (fetched 30 July 2026): Free "$0" with 100 conversations; Plus "$150/mo billed annually" with 250 conversations and top-up packs of 100 at "$65 ($0.65/convo)"; Team "$750/mo billed annually" with 1,500 conversations and top-ups at "$50 ($0.50/convo)". Storage add-on "$40/mo".

Watch out for: conversation as a billing unit has no defined length, so a long troubleshooting session costs the same as a greeting. Good for budgeting, bad for optimisation.

Verdict: honest, legible, scoped to a narrower job than the enterprise platforms above. Apply Questions 1-5 only if you intend it to touch systems of record; if it answers questions and hands off to a human, most of this frame does not apply.

At a glance

Ratings are our reading of published documentation on 30 July 2026, not test results. A low score means the platform does not claim the control, not that it fails at it.

Choose which: an explicit decision path

Most roundups describe six options and then let you decide, which is the part you were outsourcing. Our recommendation, stated as conditions rather than a winner. There is no winner here and anyone naming one is selling.

The decision path: two questions about your own organisation eliminate most of the shortlist before you compare features.

Choose a hyperscaler agent platform (AgentCore, Google Agent Platform) if two engineers will own the agent runtime as infrastructure, your agents must reach systems no SaaS vendor has a connector for, and your compliance posture requires the controls to be yours. You are buying primitives and a bill you can model, not a shortcut.

Choose the suite platform matching your system of record (Copilot Studio, Agentforce) if roughly two thirds of the data your agents touch already lives in that suite. The identity and audit inheritance outweighs the flexibility you give up, and it is the fastest honest route to a first production agent. Accept the lock-in explicitly and write down what leaving costs.

Choose a framework plus a managed control plane (LangGraph and similar) if your agents are a product feature rather than an internal tool and you already have the identity and secrets infrastructure a product team needs. Then govern them somewhere else, because the framework will not.

Choose a conversational platform (Botpress and similar) if the agent's job ends at a conversation or a handoff and systems of record stay behind a human. A smaller purchase, frequently the correct one.

Choose nothing yet if you cannot name the owner of your first agent. That is Question 1 applied to your own organisation, and with only 7.2% of organisations reporting a named accountable individual in the Gravitee data, it is the category's most common failing condition.

When you should not buy an AI agent platform

The case against this purchase is stronger than vendors admit. Three situations come up often enough to name.

Your workflow is deterministic. If inputs are structured and the rules do not change, reasoning adds cost, latency and variance to something a scheduled job already does correctly. Agents earn their keep on messy inputs and ambiguous branching. If your existing automation platform handles it, keeping it is a competent decision, not a laggard one.

You have one use case and one team. A platform is a multiplier on shared infrastructure: a registry, a policy layer, a connector catalogue, an audit trail. With one agent and one team the multiplier is 1, and you are paying the platform premium for coordination you do not need. Build it in a framework, keep it small, revisit when the second team asks for the same thing. The second team is the real trigger.

Nobody will own it. The failure we see most and the one no product fixes. An agent without a named owner drifts: scopes expand, the prompt accretes exceptions, cost stops being anybody's line item, and when the builder changes teams it becomes infrastructure nobody understands and nobody can switch off. We have written at length about why pilots stall on their way to production, and ownership is the recurring cause.

There is also a case for waiting that has nothing to do with your readiness. NIST opened its RFI in January 2026 and the resulting guidance does not exist yet. If a published federal standard will reset your sector's compliance bar, a three-year commitment now is a bet on which vendor meets a standard nobody has written. A one-year term with an exit is a defensible response.

The two failures that reach a board

Debugging difficulty and missing interoperability standards are the drawbacks the category admits to. Real, and engineering irritations. Two other failures have a different character: they arrive as a board question, and neither is solved by a better model.

An agent acted outside its authority. Not maliciously and usually not through an exotic attack. The scope it was granted was wider than the job it was given, and one ambiguous input took it somewhere the grant permitted. OWASP names the mechanism: excessive functionality plus excessive permissions plus excessive autonomy. The usual delivery route is indirect prompt injection, meaning instructions hidden in the data an agent reads. NIST's numbers show how little effort turns latent width into an exploited one: 11% to 81% against the same agent. The board question is never "how did the model get confused." It is "who approved that this agent could do that at all," and the answer is a procurement decision made months earlier by someone reading a features matrix.

Agent spend arrived unbudgeted. A retry loop, a long-context agent on a bigger document set than anyone modelled, an autonomously triggered agent whose trigger fires more often in production than in testing. What makes this unlike ordinary software overspend: the meter runs with no human present, and platforms billing in invented units make the overrun hard to notice until it clears. Microsoft's tenant-wide disable at 125% of capacity is, generously, a circuit breaker. From the service desk it is an outage caused by finance.

Both failures share a structure. The control that would have prevented them lives at the deployment layer, and the platform decision either put it there or did not. That is why we would rather you scored six documentation pages than watched six demos.

The second bill: what safe operation costs you

Every roundup prices the platform. None price the work of running it safely, which lands on your team regardless of vendor, and it is what makes a cheap platform expensive.

We are not attaching hours or salaries to those rows. We have not run a time-and-motion study on agent operations, and inventing plausible figures is what this category is already full of. What we will say: all six rows exist on all six platforms, they scale with agent count rather than usage, and a platform answering the Five Control Questions well makes them shorter without removing any.

The compliance framing: the EU AI Act's remaining obligations begin applying on 2 August 2026, with Article 6(1) following on 2 August 2027, according to the AI Act implementation timeline. Most internal agent deployments will not be high-risk systems, but the evidence you need to demonstrate that is the evidence Question 5 asks for. Our guide for AI deployers works through which obligations attach to deployers rather than providers.

Where LeapForce fits, and where it does not

LeapForce does not build agents for you and is not on the shortlist above. What we build is the layer the five questions describe: one controlled surface for every AI tool, connector, model and agent, so the answers to identity, authority, policy, spend and proof stay the same whichever platform or framework a team chose. Our AI Coworkers product runs a lifecycle we call Build, Scope, Review, Share, Improve. At the Scope step the coworker gets its own non-human identity with a named owner, the minimum connector scopes it needs, a model policy and a budget. That is Questions 1, 2 and 4 answered as one action rather than three integrations. Access and Identity treats non-human identities as first-class with owner, scope and expiry; Observability and Audit records what was refused, not only what ran. For the gateway we publish the rollout sequence we recommend: observe first, enforce second, optimize third. Enforcing before you can see traffic is how governance programmes get a reputation for blocking work.

LeapForce is in active development and the site labels per-capability build status honestly, so treat roadmap items as roadmap. If your first agent is one agent in one team, you do not need us yet; the frameworks and suite platforms above will serve you, and our analysis of promoting personal prompts into owned company assets is more useful to you today than our product is.

Honest limits and open questions

Where this frame is weakest, stated plainly.

We did not test these platforms. No bake-off, no shared task, no measured latency or accuracy. Every capability judgement derives from vendor documentation read on 30 July 2026, and documentation overstates polish. A platform documenting action-level scoping may implement it in a way your auditor rejects. Treat our scores as a filter for which demos to book, not a substitute for them.

Four expected sources yielded nothing. Gartner's research summaries and OpenAI's pricing pages returned 403; n8n's and Relevance AI's pricing tables render client-side and served no figures. So numbers a reader might reasonably expect here are absent rather than approximated.

Our 80× cost spread rests on an assumption we made up. Twenty vCPU-seconds per agent action is a reasonable guess, not a measurement. The direction of the finding survives a wide range of assumptions. The specific multiple does not.

The five questions are necessary, not sufficient. They say nothing about whether the agent works. Task accuracy, latency, evaluation tooling and fit with your data all matter and none appear in the frame. We separated them deliberately: capability is what demos measure well, control is what they measure badly. Do not read a 10/10 as a recommendation.

Vendor survey data carries vendor incentives. The Gravitee and Salesforce figures come from companies selling into the gaps they describe. We used them because they name samples and methods and because two unrelated vendors point the same way. If a neutral survey of agent governance maturity exists at that sample size, we did not find it.

The standards ground is moving. NIST's agent security work is in progress, the EU AI Act's main obligations begin applying on 2 August 2026, and the connector interoperability picture is unsettled; our look at MCP server security covers why that layer is where the instability bites. This frame will need revisiting when there is a published bar to test against.

Ready to Govern Your AI?

Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.