Speakeasy Blog

Re-reading the article, I'm confused about where I was coming from too. The article claims that it was last updated May 7th but the two Archive captures[0][1] seem to be broken for me ATM. The link to the blog source on GitHub[2] (linked from the page) just gave me a 404 and searching for the file didn't yield another location so I can't look for a commit timestamp or delta.

There is a bit of switching back and forth between speaking from an API provider and an API consumer standpoint and it is possible that in not reading sufficiently carefully I misunderstood. I was also previously oblivious to the context of the product they are marketing here that turns out to include API SDK generation (including a webhook acceptance sdk for validating requests? I don't know). The nuance that the implementer is an API provider providing both direct API access and a webhook delivery API could easily have caused me to misunderstand properly written words that flew over my head in the midst of getting bored with the content in my failure to understand it.

A great question from the article, in its current state[3], is asking: are API keys are secure enough for webhooks? In theory, you could validate a webhook request by confirming that the API key matches your in memory copy of that key. Either that or signature validation is usually supplied by the service SDK or example code that you cut and paste anyway.

Sadly, for a long time, it was too much to ask some clients to provide…

We've been a customer for the past year (https://speakeasy.com/docs). I was honestly highly skeptical about putting a RAG powered search in front of our documentation site instead of what we were using (FlexSearch / Nextra). Have been delighted to be proved wrong.

The learning I've had is that whilst the majority of queries go through standard search patterns (i.e. users search for something that's covered by documentation), a subset of queries are not answerable by our documentation but only implied by it. I've direct experience that Inkeep is serving a large part of that user segment and reducing our support burden.

As a very recent/specific example from last week, we had a community user generating a terraform provider for an internal use-case. By putting error messages from our CLI tooling into Inkeep's "Ask AI" feature, they discovered a nuance in "x-speakeasy-match" (the error message implied it created a circular reference, but didn't spell that out) and self-served a solution.

Inkeep effectively turned our documentation into a guided tutorial on our product, specific to the customer. Pretty strong ROI.

I work at Speakeasy. We build a CLI for SDK generation, and we noticed that features we designed for humans - interactive prompts, spinners, guided workflows - were actively breaking AI coding assistants.

We wrote up what we learned from fixing this:

- Non-interactive flags that bypass prompts entirely

- Structured output modes (JSON, --quiet) to reduce token consumption

- Machine-readable exit codes so agents can determine success without parsing text

The insight: you don't need separate agent-only tools. You need escape hatches that let both humans and agents use the same CLI effectively.

Full post: https://www.speakeasy.com/blog/engineering-agent-friendly-cli

I work at Speakeasy where we do a similar thing with the AI control plane (https://www.speakeasy.com/product/ai-control-plane), and we just rolled out on-device agents for the same reason.

I think the point a few people are making is right that its not sufficient to be the best at one layer like the device endpoint. AI governance needs to be coordinated over a number of surfaces. We started with an MCP gateway and drilled down to on-device agents. I imagine you might end up doing the same the other way around.