Jentic Tech Talk

API Days India 2026: August 19–21

India’s been on my radar a long time, and August is finally the month. I’ll speak at API Days India on August 19–20, then run a full-day workshop on the 21st. Looking forward to both.

The talk is “Beyond OpenAPI: API Workflows That AI Agents Can Actually Execute.” Agents call individual endpoints well enough. Multi-step workflows are where they fall apart. OpenAPI describes each endpoint but says nothing about sequencing, conditional logic, or state across calls. Agents infer all of it, burning tokens and producing results that are unpredictable at best, wrong at worst.

Arazzo fixes that: machine-readable workflow descriptions agents execute directly instead of infer. Arazzo 1.1 goes further. AsyncAPI support brings event-driven systems into the same model, so one declarative document can call an HTTP endpoint, publish to an event bus, wait for an acknowledgment, and chain the result. If OpenAPI tells agents what they can call, Arazzo tells them what to do and how to do it reliably.

The workshop goes deeper and hands-on. “Building AI-Ready APIs with Agent Skills” is a full-day masterclass I’m co-delivering with Erik Wilde: six modules with real exercises. You’ll work through OpenAPI spec improvement, Overlay-based governance, and Arazzo workflow modelling on real artifacts, not slides. The theme is incremental improvement: how to make an existing API ecosystem AI-ready without tearing it down and starting over.

It’s built for architects, platform engineers, and developers already dealing with AI agents hitting their APIs. You’ll leave with design templates and a governance model you can use next week.

If you’re attending, come say hello.

jentic-api-improve Agent Skill: Now Supports Breaking Changes

The default non-breaking mode is still right for most teams. It’s strictly additive: run it in your pipeline, ship the result, trust that nothing breaks. On its own it can move a score from the 30s into the 60s and 70s.

But some problems additive changes can’t fix: wrong response structures, required fields that were never formally described, paths that stopped making sense versions ago. The jentic-api-improve skill now has a mode=full for exactly that.

Full mode allows breaking changes and runs four improvement iterations instead of two. Every proposed change is evaluated by oasdiff before it’s applied. Breaking changes are flagged in the changelog in full detail, never applied silently. The skill surfaces the decision; it doesn’t make it for you. Breaking changes are engineering calls that need human judgment, not something an automated loop should commit to on your behalf.

Both modes produce three outputs: a revised OpenAPI document, an OpenAPI Overlay (auditable, versionable, diff-able), and a markdown changelog. In full mode the changelog includes the complete breaking-change breakdown. And the oasdiff integration is deliberate: rather than build yet another change-detection layer, the skill composes with a well-respected, widely-used tool. No reinventing the wheel here at Jentic.

Jentic API Scorecard CLI: Catch API Problems Before They Ship

Most teams find API quality problems at integration time, when an agent is already broken or burning too many tokens. By then the API is published, and fixing it means cross-team coordination, a versioning conversation, and someone’s weekend. The CLI moves those checks to where they belong.

The jentic-api-scorecard CLI offers one command that scores your OpenAPI document across six AI-Readiness dimensions: Foundational Compliance, Developer Experience, AI-Readiness, Agent Usability, Security, and AI Discoverability. About 35 signals, one overall AI-Readiness result at the end. You can run it locally before you push, in a pre-commit hook, or in any non-GitHub CI.

Note: without the --with-llm flag, LLM-backed signals aren’t evaluated. They sit at an assumed-perfect baseline, so your default score can look optimistic. Flip the flag and bring your own LLM. We can connect to almost any LLM (OpenAI, Anthropic, Gemini, Bedrock, or a local Ollama), and you get the real picture. The CLI pulls its scoring container on first run, and your OpenAPI document never leaves your environment, which matters for data-residency requirements.

Output formats cover the practical range: pretty, JSON, HTML, markdown, SARIF. The HTML report is self-contained (JS and CSS inlined), works offline, and drops cleanly into a CI artifact. SARIF lands straight in GitHub code scanning. For threshold gating, --format json | jq .summary.score gives you the number to check. We also offer a free tier: 100 scorings per month; get your key from app.jentic.com/scorecard.

arazzo2openapi: Register Workflows as APIs in Your Existing Infrastructure

Integrating API capabilities is never about a single endpoint. It’s about a use case: a series of calls that deliver the value, and discovering and invoking them safely is hard for agents and humans alike. Most API management infrastructure (gateways, developer portals, registries) speaks OpenAPI. Arazzo workflows don’t fit that model without native support, so they sit outside the governance and discoverability machinery teams already built.

I built arazzo2openapi to close that gap. It converts Arazzo 1.0 workflow documents to OpenAPI 3.0 or 3.1, so you can register a workflow as an abstract API in the infrastructure you already run. Your gateway manages it, your developer portal surfaces it, your agents discover it alongside everything else. The workflow becomes a governed, discoverable capability instead of a YAML file living outside the system.

The type inference matters. Inputs and outputs are derived from the source OpenAPI documents the workflow references, not made up. Types, formats, enums, constraints, $ref resolution: all carried through. The generated document reflects what the workflow actually does, not a generic approximation.

The payoff: teams building capability-based architectures expose Arazzo workflows through the same governance model as everything else. Same access controls, same discoverability, same consumer experience, whether that consumer is a developer browsing a portal or an agent querying a registry at runtime. No install required to try it, the playground runs in the browser.

CLI

arazzo2openapi workflow.yaml -o openapi.yaml