On the latest episode of the Naftiko Capabilities podcast I sat down with Patrick Kelly, co-founder of Sideko and Port of Context, for a wide-ranging conversation about context engineering. What emerged was a fascinating look at the same problem from two very different vantage points: one tactical, one strategic.
The Shift From SDKs to Agents
Patrick shared how Sideko started as an API tooling company, helping teams turn API specs into polished developer products — documentation, SDKs, and mock servers. Customers like Prudential were on board, and things were humming along. But a shift was underway. The primary consumer of APIs was no longer just a human developer writing integration code — it was increasingly an agent.
When the "code mode" technique surfaced (essentially giving an agent an SDK and letting it execute functions), Patrick and his co-founder Elias recognized the opportunity. Their SDK generation expertise could be reapplied to this new domain. That realization gave birth to Port of Context, focused squarely on the emerging discipline of context engineering.
My Journey: From API Governance to Context Windows
I brought a different but complementary history to the table. Years spent in the API management world — working with companies like 3scale and Apigee, helping build SDK and API transformation tooling, and a four-year stint at Postman — gave me a deep appreciation for how an OpenAPI spec is far more than a static source of truth.
People tend to see it as a source of truth for the whole menu, so I've long stopped seeing it like that. If it's well tagged and has the semantics, you can slice and dice it any way that you need.
That philosophy now drives what I ambuilding at Naftiko: an API consumption gateway that helps enterprises define their stack as a set of sandboxes — safe, mockable environments where teams can experiment with AI workflows against realistic representations of their production APIs. I am mapping enterprise toolchains by parsing job postings, building context windows tailored to specific conversations, and organizing thousands of API operations into tagged capabilities.
Two Sides of Context Engineering
The heart of the conversation was the contrast — and overlap — between our approaches.
Patrick's focus is tactical and runtime-oriented. Port of Context translates upstream MCP servers and tools down into a minimal, efficient interface — sometimes as few as three tools: list what's available, get details, and execute code. The challenge is precision. Changing a single sentence in a tool description can make or break an agent's performance, and measuring the impact of that change is genuinely hard. Patrick's team is building evaluation frameworks that go beyond surface-level LLM output checks to actually inspect the state of upstream services after an agent acts. They're also mapping which context engineering techniques work best with which models — recognizing that what performs well on Sonnet may differ from what works on Opus.
My focus is strategic and governance-oriented. I am thinking about how enterprises organize their API assets, how they tag and categorize operations, and how they produce MCP servers that are discoverable, standardized, and well-governed. I see a messy landscape where some teams generate MCP servers from clean OpenAPI specs while others spin them up ad hoc with no standards in place. My work at Naftiko aims to bring order to that — not by locking things down, but by providing the scaffolding (catalogs, sandboxes, governance rules) that makes the chaos manageable.
As I see it: Patrick is in tooling land. I'm in resource land. Patrick is more tactical. I'm more strategic.
Where the Two Approaches Meet
Both myself and Patrick acknowledged that the ideal state requires both perspectives. Enterprises need to think strategically about their API assets — clean descriptions, proper tagging, good examples — and they need tactical runtime systems that help agents navigate those assets efficiently. The governance layer and the execution layer aren't in competition; they're complementary.
Patrick highlighted a practical example of the overlap: linting rules. Sideko originally built linters for SDK generation — checking that examples matched schemas, for instance. Now, with MCP generation, the rules are different. Descriptions matter more than ever because they become the tool descriptions agents rely on. Catching lazy duplication (where a short summary and a long description field say the exact same thing) is suddenly a real issue when that text is what an AI model uses to decide which tool to call.
Looking Ahead
The conversation closed with a shared sense of possibility — but alsohumility. I openly admitted he's still learning the specifics of context engineering. Patrick acknowledged the landscape is moving so fast that techniques change before you can fully evaluate them. But both see the value in open collaboration: sharing artifacts, open-sourcing foundational layers like OpenAPI definitions and examples, and competing on the value they add rather than hoarding the raw materials.
It was a longer episode than usual — about 25 minutes — but one that earned its 25 minutes. If you're working at the intersection of APIs, agents, and AI, this is a conversation worth your time.
The Naftiko Capabilities podcast publishes episodes every Tuesday and Thursday. If you have stories to share, reach out to Kin Lane on LinkedIn, Bluesky, or at kinlane@naftiko.io.
