.jpg)
PlatformCon ran a couple of weeks ago under the tagline "The age of AI runs on platform engineering," but the agenda was really more about the impact of agents, not just AI in general — with a Gartner analyst roundtable on benchmarking whether your platform can support autonomous agents, a Coder session on deploying coding agents safely in the enterprise, and a roundtable on agentic development in regulated industries.
To be blunt, as we enter the second half of 2026, your developers have probably adopted agents already, with or without explicit platform team support.
Coder's AI maturity assessment of 100 engineering organizations found 61% running agents of some kind, mostly multi-step agents under human direction, along with a small vanguard of event-driven agents that propose their own pull requests.
The same assessment found 70% of those teams running agents on infrastructure that was never designed to support them, and governance in a state the authors summarized as "exists on paper but not in practice": a quarter of organizations had no formal AI policies at all, 44% had early policies written for limited pilots, and just 7% had anything you could call mature, cross-functional governance.
In other words, developers made the adoption decision, and the consequences are landing on the platform team.
Anyone who's been in IT for a couple of decades will have seen this same trend play out before, like in the early days of cloud, when shadow IT created a whole security and finance nightmare for enterprise teams.
Two Gartner numbers that only make sense together
Gartner predicts that 40% of enterprise applications will embed task-specific AI agents by the end of 2026, up from under 5% in 2025. These agents might be reviewing invoices for a finance team, triaging candidate applications for HR, or developing priority lead lists for sales teams. There are applications for independent agents to perform end-to-end tasks across almost all teams and workflows.
But Gartner also predicts that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. How can both be true at once?
Note that none of the three big reasons for cancellation are about model capability. Costs escalate when nobody meters or caps consumption; business value stays unclear when nobody measures outcomes; and risk controls tend to stay inadequate when the governance policy only exists as a PDF on the intranet (yeah, we've all got one of those, haven't we?).
To our eyes these are problems with the operating model around the technology — and building operating models for shared infrastructure is what platform engineering does for a living.
So our bet, and it is a bet, is that much of Gartner's predicted 2027 cull is avoidable, and that the projects that survive will disproportionately be the ones running on platforms that treated agents as production workloads from day one. Stick with me as I explain.
An agent is a workload with opinions about your architecture
Strip away the hype and an agentic workload is a long-running, stateful, tool-wielding consumer of inference. Each part of that description breaks an assumption most enterprise platforms were built on.
The most obvious difference is traffic shape. A chat assistant is bursty request/response, while an agent runs a continuous loop of planning, tool calls, and evaluation, fanning out into parallel sub-agents when a task calls for it. If your autoscaling is tuned to CPU thresholds, it's watching the wrong signal, because queue depth and token throughput are the numbers that matter now. Context makes everything heavier, too: long agent sessions pile up serious amounts of KV cache state, and our partner WEKA has documented how the token demands of agent swarms collide with the memory available to serve them. There's a reason cache offload to fast storage has become a mainstream architecture conversation this year.
Blast radius is the next thing to think about. An agent executes against real systems with whatever credentials you handed it, which makes isolation a first-order design constraint: sandboxed, ephemeral execution environments, distinct identities for non-human actors, and least-privilege credentials that expire. A developer laptop with a long-lived admin API key in an environment variable was already a bad idea. Hand that laptop to an agent and you've automated the bad idea.
At the tool layer, MCP has emerged as the standard interface between agents and enterprise systems, and that makes MCP servers and gateways the natural place to enforce policy — which tools an agent can see, which actions need approval, what gets logged. It also makes them an attractive new attack surface. Anything that holds credentials and executes instructions generated by a language model deserves at least the scrutiny you'd give a public-facing API. How many of the MCP servers already running in your estate have had that level of review?
Agents also bring some novel failure modes. A runaway loop burns tokens at frankly terrifying speed, and a retry storm can hammer a downstream API that was sized for polite human traffic. Perhaps even more dangerous is the agent that fails successfully, producing a plausible change that happens to be wrong. Quotas, budgets, and kill switches take care of the first kind; the second calls for observability deep enough to attribute any change in your estate to the agent, prompt, and tool call that produced it — a topic we've written about in depth.
Governance for the agent gray areas
Most of the organizations in Coder's 44% pilot band run what you might call binary governance: a tool is either approved or blocked. That works tolerably well while adoption moves at human speed, but it struggles once agents are operating across dozens of repositories and clusters, each with its own sensitivity levels and compliance requirements, at a pace no review board can keep up with.
Alternatively, we can look at some form of tiered risk model where read operations are on by default, changes that touch anything sensitive need a review, and destructive actions sit behind multi-party approval, with a central policy point applying the rules consistently and logging each operation in enough detail for retros or audits.
Of course, control has a price, and (a familiar conversation at platform engineering events over the years) it's often paid in developer patience. Lock the platform down too hard and you recreate shadow IT with API keys: developers running agents from personal machines against production endpoints, invisible until the incident review. The ideal is to make the governed path also the fastest path, so the sandbox with the right credentials and guardrails is easier to reach than the workaround. Of course that's very easy to say and much harder to build.
We've felt the cost of that posture ourselves. When we shipped the Palette MCP server in tech preview, we disallowed its destructive actions (deleting clusters and cluster profiles) by default, so you have to turn them on explicitly. The friction is deliberate, and yes, it means the first session can feel a little underwhelming. We'd rather have you flip a switch on day one than sit in a meeting on day ninety working out why an agent was able to delete a production cluster.
Start here while the agent count is still low
Improving agent governance doesn't require a big-bang program. If we were advising a platform team today, we'd start with five things.
- Inventory what's already running. Coder found 72% of teams scaling AI out of informal experimentation. Assume there are agents in your estate that predate any policy, and go find them before an auditor does.
- Give agents a golden path. Offer standardized, sandboxed, ephemeral environments with scoped credentials, published the same way you published golden paths for microservices. Agents and humans should work under the same constraints in the same governed environments, because that parity is what makes output reproducible and incidents attributable.
- Default-deny writes. Grant read access broadly, gate write access explicitly, and put destructive actions behind multi-party approval, starting with MCP servers and gateways, since that's where agent capability gets granted.
- Plan inference like a utility. That means queue-depth-based autoscaling, token budgets per team and per workload, and GPU capacity planning that assumes always-on consumption. If agents become a critical part of application behavior, as Gartner's 40% figure implies, inference availability will be a foundational part of business availability.
- Instrument business outcomes. Only 10% of organizations in Coder's assessment tie AI adoption to business outcomes. Cycle time, defect rates, and cost per task delivered are a few levels down from true outcomes like revenue or customer satisfaction, but for now they are the numbers that will defend your agent program when the 2027 budget conversations arrive.
Our lane is the infrastructure underneath the agent
At Spectro Cloud we don't sell an agent framework, and we're a little skeptical of the overnight rebrands from some vendors (Gartner calls the phenomenon "agent washing" and estimates that only about 130 of the thousands of self-described agentic vendors are the real thing). But we are happy to make recommendations to help you cut through the clutter and hit the ground running — we work with some of the more popular agent frameworks, and can vouch for the ones that work well in enterprise use cases.
For our part, what we build is the production substrate that agents, and agent frameworks, rest on. PaletteAI is an infrastructure platform for platform engineers like you. It manages the full stack from bare-metal GPUs to Kubernetes to model serving, across data center, cloud, and edge. With WEKA and NVIDIA we've validated a reference architecture for keeping inference fed with data at the throughput agent fleets require. We're a supporting member of the Agentic AI Foundation, the Linux Foundation body stewarding standards like MCP. And when we build agent tooling of our own, we build it governance-first, as the MCP server's defaults show.
If 2026 is the year agents arrive in the enterprise, 2027 looks likely to be the year they get audited. Our advice for the next 6–18 months is to treat agents the way you've always treated production workloads: let them earn trust through isolation, observability, and governance the platform applies by default. None of this is glamorous, and very little of it is truly new… we all just need to lean in and do the work.
If you'd like to dig further, we've written about the enterprise AI trends we're watching in 2026 and using observability to trace agentic AI decisions, or you can try the Palette MCP server and inspect its defaults for yourself.