AI adoption is nearly universal, yet transformational results remain rare. The gap between using AI and getting real value from it comes down to one thing: your platform. Justin Billig and Dan Rye from Tensure joined the Platform Engineering Community to explain what separates the 8% of teams seeing transformational ROI from everyone else - and what you can do about it.

Main insights

• Only 8% of teams in the State of AI in Platform Engineering research report transformational ROI from AI, despite near-universal adoption.
• Agents need three things from your platform: context (what exists), execution (how to act safely), and governance (what they're allowed to do and proof of what they did).
• The better your guardrails, the more autonomy you can safely grant your agents.
• Writing code is no longer the bottleneck. Business decisions, specifications, and platform readiness are.

Justin Billig is Managing Partner and CEO at Tensure, with a career built in technology consulting. Dan Rye is CTO and Partner at Tensure, with deep roots in software engineering and application architecture. Tensure works extensively in financial services, where risk management, governance, and security are non-negotiable. Their field experience gives them a grounded, practical view of what agentic engineering actually requires from a platform.

You can watch the full discussion here if you missed it.

The ROI gap

Sam, who hosted the session, opened with a striking finding from the State of AI in Platform Engineering research: only 8% of teams report transformational ROI from AI, despite near-universal adoption. The problem is not whether teams use AI - it is whether their platform is ready to support it.

Every team in that 8% met a specific set of platform requirements. Justin and Dan organized those requirements into three areas: context, execution, and governance.

Why agents change the platform conversation

The shift to agentic engineering is not just about speed, though the speed gains are significant. Tensure's internal delivery data shows that greenfield work that once took 12 weeks now takes roughly one week on a platform built for agents. Non-greenfield work that took three weeks now moves at about a third of that pace. These are Tensure's internal figures, not industry benchmarks, but they illustrate the scale of change.

More importantly, the nature of the work changes. Teams are moving from copilot-style chat inside an IDE to running multiple agents simultaneously that pick up stories and write code autonomously. As Justin put it, "writing code is no longer the bottleneck of engineering."

Your platform has historically served people. Now it must also serve agents acting on your behalf - and accountability does not move with the work. If an agent brings down a production environment, the platform and engineering teams bear responsibility. That reality shapes everything that follows.

Requirement 1: Context

Agents must know what exists and how it fits together. Much of that knowledge has historically lived in the heads of experienced engineers - who knows which API is brittle, which service has undocumented dependencies, which machine needs attention every Friday. That knowledge must now be discoverable.

Good context includes:

• Service discovery: What services exist, how to access them, their dependencies, who owns them, and which environments and infrastructure they run on.
• Organizational knowledge: Your preferred patterns, documentation standards, and runbooks that let agents - and new team members - build the right solutions.
• MCP interfaces: Model Context Protocol (MCP) servers give agents a structured way to query your systems. Justin noted that every major SaaS vendor is shipping one, and platform teams must decide which MCP capabilities to deploy internally.
• Permission-aware access: The same least-privilege principles you apply elsewhere, including delegated permissions scoped appropriately for agents.

A practical tip from the Q&A: record a conversation with the person who built a system. Ask why they built it that way and what the current documentation gets wrong. Then use AI tooling to produce updated documentation from that recording. Dan added that transcribed meetings and chat history are often an untapped source of institutional knowledge - mine that data to build a knowledge base rather than relying solely on current documents and people.

Requirement 2: Execution

Once an agent knows what to do, how does it act safely, consistently, and securely? This is where platform teams can extend expertise they already have.

Execution depends on:

• Golden paths and self-service workflows: Agents deploy through paths the platform team manages, not by building infrastructure themselves.
• Invocable automation: Just as you avoid click-ops for humans, agents must not file tickets for people to action. Automation must be callable, and MCPs can expose it.
• Isolated, ephemeral environments: Agents need sandboxed spaces to validate changes before they reach production, then tear those environments down.
• Approved specs and templates: Agents start from specifications that meet both business and technical requirements, reducing the risk of drift.
• Expanded pull request checks: Agents can review pull requests for security, governance, and platform best practices - not only code completeness.

Cost is a real concern here. Agents can spin up projects far faster than humans, and untagged resources accumulate quickly. Justin was direct: "If they have a manual process, agentic delivery isn't going to scale." Repeatable execution paths with correct tagging built in prevent the retroactive conversation with finance about a surprising cloud bill.

Justin also raised a broader question worth sitting with: when code can be rewritten in minutes, is code still the asset you must protect? Or are context, specifications, and business requirements now the most valuable things your team produces? This is his perspective on where things are heading - not an established fact - but it is a useful frame for prioritizing platform investment.

Requirement 3: Governance

Justin described the core challenge as giving agents "useful autonomy without losing control." A well-defined governance structure is what lets engineering teams move quickly - not a constraint on speed, but the foundation of it.

Governance includes:

• Agent identity: Agent identities may not tie to a specific person. You need to know which agents act against which systems, prevent escalated permission sets, and scope credentials and secrets correctly.
• Policy as code: Compliance rules that humans once applied from memory must be written as code that agents pull in, enforce, and flag when they cannot meet.
• Audit and observability: What changed, which agents acted, why they acted, and whether they attempted to act beyond their expected scope.
• Human-in-the-loop checkpoints: Define clearly when agents can deploy and modify code autonomously and when a person must approve. Independent agents can also review and test to confirm governance is followed.

The central principle from the session: "The better your guardrails, the more autonomy you can grant your agents." Governance is not the brake on agentic engineering - it is what makes expanding agent autonomy safe over time.

Why you need all three

These three requirements depend on one another. As Justin put it, "The maturity of your platform is going to define the maturity of your agentic engineering experience." A gap in one pillar limits the other two. Before agents, you could rely on colleagues to follow governance that was not enforced in code and to know where to find information. Neither assumption holds for agents.

To assess your own readiness, Justin and Dan suggested three diagnostic questions:

1. Can agents find what they need about your systems, dependencies, and engineering rules? If they cannot, they may fabricate answers.
2. Can agents run common engineering workflows through standardized processes, and do your existing processes need to change to support agents?
3. When something changes, can you prove what was accessed, what changed, and which controls applied?

Where to start

Justin recommended picking one area of your organization, running agentic delivery end to end, and closing the gaps you find across context, execution, and governance. Then expand agent autonomy incrementally. Tensure also publishes a maturity model on its website that outlines the levels organizations move through.

On prioritization: start with your weakest area. Execution is often the strongest because teams have already invested in software delivery automation. Governance documents tend to attract many reviewers in regulated industries - but do not wait to start. Your engineers are likely already using these tools, with or without a platform to support them.

The Q&A surfaced a few additional themes worth noting:

• Build versus buy: Dan observed that customers increasingly question the traditional 80% trade-off, asking whether they would pay more to get exactly what they need. Security tooling still tends toward buying, where vendors take on liability. Productivity tooling is moving in-house.
• Business users as platform customers: Nearly 40% of platform teams surveyed serve business users in functions like marketing, legal, and finance. Dan recommended starting with an audit of what those teams have already built. Justin encouraged platform teams to embrace this expanded scope - it raises the platform's organizational importance.
• Token spend: Expect elevated bills in the first months after opening access broadly. Dan noted that enterprise accounts can cost roughly 10 times more than smaller team accounts. Treat token spend like cloud spend: put limits and reporting in place from the start.

​

If you enjoyed this, find here more great insights and events from our Platform Engineering Community.

If you want to dive deeper, explore our instructor-led Platform Engineering Certified Professional course and connect with peers from large-scale enterprises who are driving platform engineering initiatives.

​

Key takeaways

• Audit your platform against all three pillars. Agents amplify whatever maturity you already have. A gap in context, execution, or governance limits the other two. Identify your weakest area first and close it before expanding agent autonomy.
• Make implicit knowledge discoverable. Build service discovery, document ownership and dependencies, and expose them through MCP interfaces. Recording conversations with system experts is one of the fastest ways to capture tribal knowledge before it walks out the door.
• Give agents approved paths, not open access. Golden paths, ephemeral environments, tagged resources, and expanded pull request checks keep agent-driven delivery fast and safe - and prevent cost surprises that erode executive confidence.
• Treat guardrails as the enabler of autonomy. Agent identities, policy as code, audit trails, and clear human checkpoints let you grant agents more freedom over time. They also position your platform team as the organization's trusted enabler of AI - not a bottleneck to it.