Agents in production
Platform integration
An agent readiness framework tells you whether your SaaS is ready for AI agents. Capability-first vs layer-first compared, with when to use each in practice.
Every established SaaS company is being asked the same question by its board, its biggest customers, or its own AI team: are we ready for agents? The honest answer is usually a shrug, a slide deck, or a demo of the one workflow that works. None of those hold up in a real evaluation.
An agent readiness framework is the structured way to answer that question. It's not a maturity model in the abstract-consulting sense — it's a diagnostic that tells you which layer of your platform will break first when an agent tries to do real work on it. This piece compares the two frameworks teams actually use: the capability-first framework (score what agents can do today) and the layer-first framework (score each layer of the stack against agent load). Both have a place. Neither one is enough on its own.
If you're a Head of AI or CTO trying to build a defensible answer to "are we ready" — one that survives a board question and a customer's security review — this is the comparison to read first.
The capability-first framework starts from the outside in. You list every workflow your product supports through its UI, then score each one on whether an agent could execute it end-to-end today. The score is usually a four- or five-point scale: unreachable, partially reachable via API, reachable but not production-safe, agent-ready.
The output is a coverage percentage. If your product has 400 UI-exposed capabilities and agents can reach 80 of them safely, you're at 20% agent-ready. That number is easy to communicate, easy to trend over time, and easy to turn into a roadmap. It's what most teams reach for first because it maps to how executives already think about product surface.
Where this framework earns its keep is prioritisation. It tells you which capabilities matter most (usually by revenue, usage, or strategic weight) and how far each one is from ready. It gives product managers something concrete to sequence. Teams who've read our take on agent-ready products vs API products will recognise the shape — this framework is the operational version of that argument.
Where it falls short is diagnosis. A capability score tells you what isn't ready. It doesn't tell you why, and it doesn't tell you what will break next. Two capabilities scored "partially reachable" can have wildly different underlying causes — one might need a new endpoint, the other might need the entire auth model rethought. The framework flattens that distinction, which is fine for reporting and misleading for planning.
The layer-first framework starts from the inside out. Instead of scoring workflows, you score each layer of the stack against the demands agents will place on it. A typical model has six or seven layers: API surface, auth and identity, rate limiting, observability, tool contracts, runtime execution, and change management. Each layer gets assessed independently, usually against a rubric of specific failure modes.
The output isn't a single number. It's a heat map. You end up with a picture of your platform that says: the API surface is amber (covers 60% of UI capabilities), auth is red (still uses shared service accounts for agent traffic), observability is green (per-call tracing already in place), rate limiting is red (per-tenant limits will break under agent burst load). The heat map tells you where to invest and, more importantly, in what order.
This is closer to how engineering leaders already think — layered systems, layered failure. It also aligns with the questions security reviews actually ask. "How do you enforce least privilege for agents?" isn't a capability question; it's a layer question. Same for zero trust, audit trails, and change management.
Where layer-first earns its keep is engineering credibility. A CTO can defend a layer-first score to a board or a security team in a way a capability percentage can't. Where it falls short is commercial framing. "Our auth layer is amber" doesn't translate to "we can close the deal that needs Salesforce-grade agent access." The layer view is technically honest and commercially quiet.
Run capability-first when the pressure is commercial. If your board is asking whether you can compete for agent-native deals, if your biggest customer just asked for an agent readiness statement, or if your product marketing needs a number to put in a keynote, capability-first is the right tool. It's also the right first pass for any company that's never done an agent readiness assessment before — the workflow inventory alone will surface things you didn't know about your own product.
Capability-first also wins when the answer needs to be legible to non-engineers. A coverage percentage that trends up quarter over quarter is a story a CEO can tell. A heat map isn't.
One caveat: don't confuse the score with the plan. A 20% coverage number tells you where you are. It doesn't tell you how to get to 60%, and it doesn't warn you that the path from 20% to 60% might require rebuilding a layer that isn't in the framework at all.
Run layer-first when the pressure is technical. If you've already got a pilot agent in production and it's fragile, if security has flagged questions about how agents authenticate, if your engineering team can't agree on whether the next investment is API surface or runtime — layer-first gives you the shared vocabulary to make that call.
Layer-first also wins under scrutiny. When an enterprise customer's architecture review asks how you handle agent identity, delegated auth, or rate limiting under agent burst patterns, the answers come out of a layer-first assessment. A capability score won't survive that meeting.
And layer-first is the right framework when you've already done a capability assessment and the results feel dishonest. If you scored 40% ready but every deployment fails at the auth boundary, the capability number is telling you the wrong story. Layer-first will find the actual bottleneck.
Most teams end up needing both frameworks — capability-first to sequence what to fix, layer-first to know what "fixed" means at each layer. The bottleneck almost always shows up at the same two layers: API surface (the capabilities exist in the product but not in the API) and runtime (the API exists but doesn't hold under agent identity, rate limits, or observability requirements).
Those are the layers Pontil operates on. Tools-as-a-Service generates agent-callable tools from the codebases and APIs you already own, and runs them through a runtime that executes as the authenticated user — the two moves that turn a layer-first "amber" into a defensible "green" without what can otherwise be a multi-year API rewrite. If your readiness assessment is pointing at the tools layer, the product page walks through what that looks like in practice.
Run capability-first once, at the start. Do it fast — four weeks, not four months. The point is a baseline and a rough map, not a masterpiece. Then run layer-first against the top three capability gaps and let the layer view drive the actual investment.
The teams we see get stuck are the ones that pick one framework and refuse the other. Capability-first-only teams end up with a roadmap that keeps missing its dates because the underlying layers aren't ready. Layer-first-only teams end up with a beautifully diagnosed platform that nobody outside engineering understands or funds.
The framework isn't the goal. The goal is a readiness answer that survives three audiences: the board, the security review, and the engineering team that has to build it. Neither framework does that alone. Both together, run in the right order, do.
Stay up to date on the ever changing agentic landscape.
GET STARTED
Start with a 30-minute discovery call
contactus@pontil.com
