Pontil tools

Your agents can reason.
They just can't act.

Your product can do it. Your agents can't reach it. Pontil Tools generates agent-ready tools from your existing codebase — surfaced at runtime, scoped to the authenticated user, with no backend rewrite.

The problem

The agent API gap: why your platform isn't agent-ready

Most agent projects don't stall because the model is wrong. They stall because the product the agent needs to act on isn't reachable.

Your internal APIs cover a fraction of what your product actually does. The rest lives in controller logic, UI workflows, and business rules that were never meant to be called by a machine. An agent can reason perfectly well about what it should do, then hit a wall when it tries to do it — because the path to that capability doesn't exist in a form it can call.

The gap is widening, not closing. Across more than 5,700 developers surveyed in Postman's 2025 State of the API report, 89% now use generative AI in their daily work — but only 24% design their APIs with AI agents in mind. The product surface and the agent demand are moving in opposite directions. Building the missing surface by hand is a two-to-five-year project most teams can't fund against the roadmap, so the agent work waits.

Diagram showing how Pontil connects AI agents to existing platform APIs

“Over 40% of agentic AI projects will be cancelled by end of 2027 due to inadequate infrastructure foundations.”

Gartner, June 2025
how pontil works

Turn existing capability into agent tools

Pontil Tools turns the capability already built into your product into tools an agent can discover and call — at the permission level of whoever it's acting for. You decide what gets exposed; Pontil keeps it current as the product changes. It's the producer side of the agent-tools market: exposing your own product outward to agents, not pulling third-party data inward. That's the job most of the market doesn't do.

01 — Generation and sync

Pontil scans your codebase

No manual docs, no new API surface to build first. The scanner reads what's already there — controllers, resolvers, routing — and generates structured, annotated action definitions from the APIs your product already exposes. Source stays in your environment.

Diagram of Pontil scanning a codebase to discover existing APIs
02 — Tool mapping

You compose and approve the tools

Raw actions map to low-level calls; tools map to the tasks someone would actually ask an agent to do. Your team composes tools from the generated actions, with AI assistance and human review at every step. Destructive operations aren't exposed by default. You define what an agent can reach.

03 — Tool runtime

Tools run through the managed runtime

Deterministic invocation, retries, timeouts, rate limiting, and observability — handled at the runtime layer, not pushed onto your agents or your product. Every call executes as the authenticated user, with their permissions, their data visibility, and their audit trail. No shared service account.

Diagram of Pontil's managed runtime executing tool calls as the authenticated user
04 — Agent SDK

Agents discover tools at runtime via the SDK

Current definitions are fetched at call time, scoped to the user and tenant. When a tool changes, agents pick it up without a redeploy. The SDK sits alongside your existing framework rather than replacing it, and the runtime is callable over HTTP for anything the SDK doesn't yet bind.

Diagram of Pontil's Agent SDK as the interface between agents and the runtime

“89% of developers use generative AI daily, but only 24% design their APIs with AI agents in mind.”

postman, state of the api report, 2025
Pontil tools

Where Pontil fits

Pontil Tools is built for teams shipping agents against their own product — not orchestration frameworks or browser-automation workarounds that reverse-engineer the UI. Because generation runs against systems you own, it plugs into your engineering practice: CI triggers regeneration, tests point at the generated tools, your SIEM reads the audit trail. Reverse-engineered approaches can't — no contract, no way to catch silent drift before production.

MCP awareness runs ahead of adoption: 70% of developers know the Model Context Protocol but only 10% use it regularly. The point holds whichever standard wins — agents are already calling your APIs, and that surface needs to be generated, governed, and maintained. Pontil Tools outputs MCP-compatible format alongside REST, so you're not betting on one protocol.

RESOURCES

Go deeper

API strategy

Agents in production

Why agent projects stall

15 minute read

API strategy

Agents in production

Agent projects stall at the same point. Here's why

15 minute read

Platform integration

Agents in production

AI applications in enterprise SaaS: why most can't reach their own products

10 minute read

pontil

One platform, three solutions

One engine — generation, runtime, and maintenance — pointed three ways. See how it works across all three, or read the security model for the trust-boundary and auth detail.

Frequently asked questions

Does Pontil need a published API spec (OpenAPI/Swagger) to work?
How does this handle APIs that were never publicly documented?
What happens when our product changes?
Does this lock us into a specific agent framework?
Do agents have to redeploy when a tool updates?
How does it work for multi-tenant SaaS?